If I share a folder, it does a "primary" share on the folder, but then all sub-folders and files get a "secondary" share on them according to the help text. What I am trying to do is share a project so that each individual file or folder can be branched by breaking the share. I think I am looking for a primary share on all files.
How do I do this without manually sharing all 5000 files in my project?
Primary Share a tree of folders and files
Moderator: SourceGear
The GUI client does not have a shortcut to create a similar folder structure, and then share all the files within a folder. There is an enhancement item to add this functionality to the GUI client. I've added your name to the list of customer's requesting the feature.
As of Version 3.1.x and earlier, the Vault GUI client only shares the folder. This is a really powerful feature when it comes to using a common library in which added / deleted / renamed files are a required within the main folder in order to make sure the library is in one piece.
About the only work around would be to create an empty folder structure in the repository, and then share all files per folder level. This should only take n operations, where n is the number of folders in your sub structure.
Note, unless it is absolutely critical for your process to share each individual file, I'd recommend looking at the folder level share. This will reduce the number of resources used in the server to track links for shared objects.
As of Version 3.1.x and earlier, the Vault GUI client only shares the folder. This is a really powerful feature when it comes to using a common library in which added / deleted / renamed files are a required within the main folder in order to make sure the library is in one piece.
About the only work around would be to create an empty folder structure in the repository, and then share all files per folder level. This should only take n operations, where n is the number of folders in your sub structure.
Note, unless it is absolutely critical for your process to share each individual file, I'd recommend looking at the folder level share. This will reduce the number of resources used in the server to track links for shared objects.
Jeff Clausius
SourceGear
SourceGear
n=1,174
There are 1174 folders in my project, so n is too high.
In my use case, we have a 1.x project where changes will be limited to bug fixes only. The 2.x project will allow bug fixes and enhancements. Ideally 2.x would start out as a primary share of all files/folders. Bug fixes would apply to both trees, but if an enhancement went in, a developer would first branch the individual files touvhed. This method requires the least amount of double-coding, double code maintenence and at a glance you can see if code has been enhanced(not shared icons) and know whether you need to take special precations applying the same bug fixes to the new code. The secondary sharing is useless for this, and my only option is doing a full branch of all files, and double entering all bug fixes.
Do you have a date/version for this enhancement?
In my use case, we have a 1.x project where changes will be limited to bug fixes only. The 2.x project will allow bug fixes and enhancements. Ideally 2.x would start out as a primary share of all files/folders. Bug fixes would apply to both trees, but if an enhancement went in, a developer would first branch the individual files touvhed. This method requires the least amount of double-coding, double code maintenence and at a glance you can see if code has been enhanced(not shared icons) and know whether you need to take special precations applying the same bug fixes to the new code. The secondary sharing is useless for this, and my only option is doing a full branch of all files, and double entering all bug fixes.
Do you have a date/version for this enhancement?
The feature is currently scheduled to Vault 4.0. While I do not have a specific time frame for this release, it is quite a ways off.
From your description, are you saying you share the entire folder's contents to maintain distinction between versions? I'm may be incorrect, but from the info you've provided would plain branching work?
For example, the Vault repository looks like the following:
$/trunk/
$/branches/
$/branches/1
$/branches/2
$/branches/3
Whenever a specific milestone is reached, the trunk is branched. The branch is then maintained for bug fixes and updates to the specific version while development can also independently progress in $/trunk.
If you do come across the situation where code needs to be changed in both places, the changes can be merged from trunk to branch or branch to trunk depending on the situation.
As you mentioned, there is more work here, but the amount of work should be manageable. The Merge Branch wizard should help propagate changes one way or another to either folder in the repository.
Edit - Added last paragraph
From your description, are you saying you share the entire folder's contents to maintain distinction between versions? I'm may be incorrect, but from the info you've provided would plain branching work?
For example, the Vault repository looks like the following:
$/trunk/
$/branches/
$/branches/1
$/branches/2
$/branches/3
Whenever a specific milestone is reached, the trunk is branched. The branch is then maintained for bug fixes and updates to the specific version while development can also independently progress in $/trunk.
If you do come across the situation where code needs to be changed in both places, the changes can be merged from trunk to branch or branch to trunk depending on the situation.
As you mentioned, there is more work here, but the amount of work should be manageable. The Merge Branch wizard should help propagate changes one way or another to either folder in the repository.
Edit - Added last paragraph
Jeff Clausius
SourceGear
SourceGear
My company is in this exact situation. In SourceSafe, one of our development groups would make a share for each release. The vast majority of their files are kept identical across all the versions, but a few are maintained separately. Having to change things twice, even with the benefit of the merge branches tool, will be too much overhead in their development style.
I had expected that I could share at the top-level folder, and then be able to branch individual files and sub-folders so that from that point on their development could be branched for those files only. As a bonus over SourceSafe, file adds and deletes would be shared unless I took steps to override this such as branching and deleting.
However, when we tried this the branch failed, complaining that it couldn't overwrite the existing file. The Vault share is a literal share, more like a symbolic link in Unix, and does not really permit the two sides of the share to differ.
What's being proposed for 4.0 is the ability to set up many shares on specific files, correct? I don't think we really want that. That's how SourceSafe works, but I'd prefer a single share that could have modifications below it. For one thing, wouldn't multiple shares be inefficient in the database? Also, as I add files, won't they fail to show up on the other side of the share? I guess the simplest way to describe what I want (and had expected) is the ability to "share with exceptions". Share this directory, except for file a.txt and b.txt which are different on each side.
I'm planning to work around this sharing issue by having all work go into the "trunk". Each release, we will just create a folder for that release with no files in it. If /trunk/file/a.txt needs to be different in version xyz, I'll create a totally unrelated file called /branch-xyz/file/a.txt. With this scheme, the correct way to get version xyz would be to get the trunk, then get xyz over the top of it.
Thoughts?
Jason Taylor
I had expected that I could share at the top-level folder, and then be able to branch individual files and sub-folders so that from that point on their development could be branched for those files only. As a bonus over SourceSafe, file adds and deletes would be shared unless I took steps to override this such as branching and deleting.
However, when we tried this the branch failed, complaining that it couldn't overwrite the existing file. The Vault share is a literal share, more like a symbolic link in Unix, and does not really permit the two sides of the share to differ.
What's being proposed for 4.0 is the ability to set up many shares on specific files, correct? I don't think we really want that. That's how SourceSafe works, but I'd prefer a single share that could have modifications below it. For one thing, wouldn't multiple shares be inefficient in the database? Also, as I add files, won't they fail to show up on the other side of the share? I guess the simplest way to describe what I want (and had expected) is the ability to "share with exceptions". Share this directory, except for file a.txt and b.txt which are different on each side.
I'm planning to work around this sharing issue by having all work go into the "trunk". Each release, we will just create a folder for that release with no files in it. If /trunk/file/a.txt needs to be different in version xyz, I'll create a totally unrelated file called /branch-xyz/file/a.txt. With this scheme, the correct way to get version xyz would be to get the trunk, then get xyz over the top of it.
Thoughts?
Jason Taylor
Yes, once we start doing this I'm not sure how I will work around that issue.
Another problem that I've realized in the meantime -- if the trunk adds a file, but the share isn't supposed to have it, how would I hide it in the share? The share is additive, but I'd need a way to "hide" the file. This would be elegantly handled if I could just do a normal share, branch the file I want to remove in the share, and delete it from the share.
So my workaround has some serious issues. Any feedback from Sourcegear developers as to the feasibility and/or timeline for sharing as we are discussing it?
Thanks
Jason Taylor
Another problem that I've realized in the meantime -- if the trunk adds a file, but the share isn't supposed to have it, how would I hide it in the share? The share is additive, but I'd need a way to "hide" the file. This would be elegantly handled if I could just do a normal share, branch the file I want to remove in the share, and delete it from the share.
So my workaround has some serious issues. Any feedback from Sourcegear developers as to the feasibility and/or timeline for sharing as we are discussing it?
Thanks
Jason Taylor
We're now considering emulating SourceSafe's directory sharing by doing individual file shares through a program that would make thousands of Vault API calls, recursively iterating through the folder structure. Before we go this route, please let me know if you expect Vault to be able to handle this type of scenario, and if you can recommend other ways to do it (other than merge branches).
Is this essentially how you will implement SourceSafe-style sharing in version 4?
Is this essentially how you will implement SourceSafe-style sharing in version 4?