Private Version Of Youtube
Scottie Marberry
I am working on SAC planning story where I would need to publish the data from a Private version to a Public version. I know there is a way to do this manually through an option "Version Management" with in the story. I would like to know if this is possible dynamically by clicking a button: data action trigger (through data action / advanced formula written in the data action) in the story.
If you planning on an implicit private version, you can publish data automatically after data action is executed. Youn can set the check box in 'Follow up action' in the data action trigger panel as below.
If you're wanting to make a patch for my high poly conversion, you MUST get permission from the mod author of the mod you're wanting to patch as well as davoker who made this mod this conversion was done for.
When you say the user can see the private version, do you mean they can access the version by adding its layers to a map and view the data (hopefully not edit it), or do you mean you can see the Default version when you click on Version Management?
@DasheEbra ,
Branch versioning does not support having the dbo user or the sde user as the data owner since it causes the behavior as you described. In ArcGIS Pro 3.0, we will be blocking the ability to register datasets as branch for these users, and the documentation will also be updated.
Apologies for the inconvenience.
I can see that we can train the base model with our private data using fine-tunings and embeddings (still trying to understand which one is the best option) but if we do train the model, do we get a private version of model like model ID or some sort of other information that can only be used by certain users and not accessed publicly?
The use case I am trying to implement is that we have large legal documents (can be 100 or so pages in some cases) and we want to build an interface for our users to select a particular document and then ask questions in the context of that document only.
These actions can be done from the website, the API, or any submission method used by the user. The user can modify the title, for example, but also another field that would not trigger a new version. In this situation, since the title has been changed, we would generate a new version that would have both the new title and the other metadata changed.
If the changes do not generate a new version, meaning they are performed on any other metadata field except the ones documented above, then they will be applied only to the latest public version.
Yes, all the rules will apply if the items are going through a curation process. The only difference is that new versions or updates to existing versions are created only when the request is approved.
Say I am developing an app for sale. Does it make sense to use a public repository for this project? Doesn't default copyright protect the code from someone else using it? If so, what advantages are there in paying for a private repository?
If your application is closed-source, it should go in a private repository. Copyright might protect you legally, but if someone decides to steal your code, they likely won't care. Then it's up to you to be able to find these people, be able to identify that they've used your source code in their application, and prove it to a judge.
This is especially problematic if you're doing something new. Maybe you've created a new algorithm of sorts, or combined web-services or APIs in a way not yet done. You're releasing your application for money, and leaving a comprehensive how-to guide online for all to see, significantly damaging your competitive advantage.
If you're handling user security in any way, any mistakes you made (and you will have) will be much more easily found and exploited if attackers can read your source code. Some online repositories have bug trackers -- people can follow that, and it will point them straight to the vulnerabilities that have been found, and will have a window to take advantage of them (the time it takes you to fix the bugs, and for your users to apply a patch).
I should also mention that if you have a team of five people or less, you can host your code privately with BitBucket for free. There are other services I'm sure, I just know of that one because I use it.
Being something of an open-source fanatic, I'd differ somewhat with Carson. He's perfectly right in a sense, but it is (in my humble opinion anyway) no big deal to open source private software either.
For all intents and purposes you could keep it unlicensed on github and it'll make no difference: the github traffic to your repo will be about zero until you release. And then, you never know -- some user/coder might bump into it and volunteer a patch, a suggestion, a feature request, etc.
Unless you're building the billion dollar application, nobody will care about your code in a material manner. And if you do, you'll have your billions already and won't care much if they have access to it. The value of your application will come not from its source code but in your ability to market, support, and maintain it.
Here I go again. I'm not a lawyer and this is not legal advice. Basically, there is nothing preventing anyone from looking at the source code and creating a derivative work from it. At the very best you can have a check-box or a registration form to restrict access if you have put this in a public repository. And then, here's the kicker, it is upto to you to establish your claim that the other party has created the derived work. It is not up to them to prove them that they didn't look at your source code; besides, it's counter-intuitive isn't it and it essentially sets up the scenario where it is your word against their word.
Based on the above, it would not make sense to create a public repository. It has to go into a private repository where you can control access to the source code. Most large companies extend access control to a much larger extent - typically a developer would have access only to the projects that he deals with, i.e. access is provided on a need-to-know basis. Anything else is asking for trouble, especially if some of the features constitute intellectual property and are being patented, or for that matter happen to be the secret sauce that lends competitive advantage to the company.
Apart from the ones listed above, the typical advantage lent by a private repository is that the contract between you and provider would essentially include a NDA. If you do not have one, then you are only paying for the services of having a repository that is supposedly private. After all, there is nothing preventing a member on the operations team of the provider from peeking into your sources and creating a derived work.
If you're going to sell the application, I wouldn't use a public repository since you're showing the whole world HOW to bypass your licensing system without spending any huge effort. If they really want to crack it, they'll get there at some point, but the investment will be much higher and thus less likely to happen right away (without going further offtopic on obfuscation etc).
The only point in which you could host the source in a public repository, is when the application should be bought in a marketplace (iphone, android, wp7, ..) and you don't have to worry that much about licenses, ... And even then I wouldn't recommend it, since people can just download the source and publish it themself (with some minor changes, ...) or install on an unlocked device.
For the copyright issue: I'm not a lawyer, but at some point you'll have to be able to prove your code was there first if you want to fight over copyright. Timestamped version history might help you a bit, but there are ways to bypass that (private hosting, ..) If you keep it private, people can't steal it (only the idea, not the actual implementation), and you won't have to deal with it.
A research group I'm participating in currently hosts all of their code in a private SVN repository. We'd like to open up our code and move most of it onto Github. The problem is, some of the code is sensitive and should not be opened up, but we still want it under version control. At the moment, we have the open code on Github and the private code still in the private SVN repository. Is there a good way to do this in a single Git repository?
With a single git repository, no. What you can do is use git submodules, which allow you to "combine" repositories. Keep your public code on github, create another, privately hosted, git repository for your private code which references the public code as a submodule. Changes made within the public submodule can be pushed up to github, and changes on github can be pulled back down, but changes outside the submodule won't be exposed to the public community. Although the code trees will be merged into a single root you will have to manage commits, pushes, and pulls independently between the separate modules, which many people find cumbersome and problematic, so you should do some experimentation with the workflow before distributing widely.
Unless you want to write git hooks to encrypt/decrypt the sourcecode you'll have to live with two repos. When someone clones a git repo they literally make a clone of it, so it would not be possible to make parts of it private without encryption.
The idea is the submodule is a public git repository embedded inside a private git repository. You manage them separately, with the advantage of the private git repository having publict repository files embedded inside of the directory structure.
Yep, git submodules seem to solve the problem for us as well. We used to develop open source CMS & premium extensions (paid) in the same branch of our private repository. Now we decided to switch the core development to github public repo and split the development.
c80f0f1006