I'm trying to figure out how I would go about doing a share in Vault from a label. To do this in SourceSafe, I would do a labels-only history on the desired source branch, pick the label I wanted, click Share, select the root folder to share to, and then I am prompted for a new folder name for the share.
Under Vault, however, I seem to only be prompted for a new folder name when I am doing a Branch. However, I do not wish to do a branch; I want to do a share. I can share to an existing folder, but then everything is down one level (buried under the new folder). I need to share at the same level.
For example, suppose I have a folder named $/Release 6.0. I would like to be able to share source (by label) in $/Release 6.0 into a new root folder, such as $/Release 6.1.
Am I missing something here? How can I share folders the way I used to under SourceSafe?
Can I share to new root-level folder?
Moderator: SourceGear
I think I see what you are trying for here. Correct me if I'm wrong.
What you would need to do in this instance to get the same thing is to create the new folder first. Then, rather than selecting the Release 6.0 folder, you would select everything inside that folder and then tell it to share. You can share an entire group of files at once to another folder.
What you would need to do in this instance to get the same thing is to create the new folder first. Then, rather than selecting the Release 6.0 folder, you would select everything inside that folder and then tell it to share. You can share an entire group of files at once to another folder.
Keep in mind that I label the root folder: $/Release 6.0.
Your solution seems just horribly inconvenient given that I numerous folders under $/Release 6.0 and I apparently cannot multi-select these folders, look up a common label (which is inherited), and do the share in a single operation. Honestly, I’m quite surprised that Vault does not mimic the SourceSafe design in this area. This is pretty much a “show stopper” in my book.
As an alternative, is it possible to share $/Release 6.0 into a folder I create (call it $/Release6.1.tmp), yielding $/Release 6.1.tmp/Release 6.0, and then somehow rename or move $/Release 6.1.tmp/Release 6.0 to $/Release 6.1?
Your solution seems just horribly inconvenient given that I numerous folders under $/Release 6.0 and I apparently cannot multi-select these folders, look up a common label (which is inherited), and do the share in a single operation. Honestly, I’m quite surprised that Vault does not mimic the SourceSafe design in this area. This is pretty much a “show stopper” in my book.
As an alternative, is it possible to share $/Release 6.0 into a folder I create (call it $/Release6.1.tmp), yielding $/Release 6.1.tmp/Release 6.0, and then somehow rename or move $/Release 6.1.tmp/Release 6.0 to $/Release 6.1?
I tried my proposed alternative and that does not work. I seem to be left with one of two choices:
But if that is not possible, I would at least like to be able to select all of the contents of a particular folder (by common, inherited label) and share this to a new folder. That would accomplish what I want to do. As is, however, Vault does not allow multi-selection on sub-folders.
I hope that you will be able to address this deficiency soon. This problem notwithstanding, you have a strong product.
- 1. Learn to like branching (which may be doable, though I would miss the auto-propagation of corrections from earlier versions to later versions).
2. Beg for sharing from the root folders.
But if that is not possible, I would at least like to be able to select all of the contents of a particular folder (by common, inherited label) and share this to a new folder. That would accomplish what I want to do. As is, however, Vault does not allow multi-selection on sub-folders.
I hope that you will be able to address this deficiency soon. This problem notwithstanding, you have a strong product.
I would recommend re-visiting branch.
Since Vault supports the notion of a folder level share, things in one folder automatically occur in the other shared locations. This is a powerful feature when you have a base library used for multiple projects.
However, when considering release level development, sharing can be very, very dangerous. You cannot control the code as changes automatically propagate elsewhere, and it takes more effort to control the environment.
For continuation of the product line, I would look strongly at label and branch. Branching allows you to work along two code paths forked at a similar ancestor. Then when code in 6.0 needs to be migrated to 6.1, it can be done so in a controlled fashion. Also, the use of labels for 6.0.1, 6.0.2, ... can be used to minimize the number of branches.
Also, if you would like to do VSS style sharing (where a folder is created an files are shared individually), please contact support at sourcegear dot com and request the Vault VSS style folder sharing Power Toy.
Since Vault supports the notion of a folder level share, things in one folder automatically occur in the other shared locations. This is a powerful feature when you have a base library used for multiple projects.
However, when considering release level development, sharing can be very, very dangerous. You cannot control the code as changes automatically propagate elsewhere, and it takes more effort to control the environment.
For continuation of the product line, I would look strongly at label and branch. Branching allows you to work along two code paths forked at a similar ancestor. Then when code in 6.0 needs to be migrated to 6.1, it can be done so in a controlled fashion. Also, the use of labels for 6.0.1, 6.0.2, ... can be used to minimize the number of branches.
Also, if you would like to do VSS style sharing (where a folder is created an files are shared individually), please contact support at sourcegear dot com and request the Vault VSS style folder sharing Power Toy.
Jeff Clausius
SourceGear
SourceGear
It can be dangerous, but we have learned (from SourceSafe) to pin the older branches so that changes do not creep in. From my perspective, it is also dangerous that a bug-fix change in an older branch may not get propagated forward (as this requires the discipline to always merge forward any changes).
That said, I’m largely in agreement with you on this in that we should get used to branching and learn to merge forward. This certainly seems to be today’s “best practice”. I’m looking into Vault’s support for that now. The biggest hurdle is re-training the rest of the development staff to use the branch / merge model instead of the share / pin model.
In the meantime, I would be very interested in the VSS style folder sharing Power Toy you describe.
Thank you.
That said, I’m largely in agreement with you on this in that we should get used to branching and learn to merge forward. This certainly seems to be today’s “best practice”. I’m looking into Vault’s support for that now. The biggest hurdle is re-training the rest of the development staff to use the branch / merge model instead of the share / pin model.
In the meantime, I would be very interested in the VSS style folder sharing Power Toy you describe.
Thank you.
I got the VSS Share Folder PowerToy quickly, thanks.
Unfortunately, however, this tool does not seem to behave any differently than the Share command in the current Vault client. I still cannot share a root folder to another root folder without burying the shared root source folder under the target root folder. This is the exact problem I described previously.
I guess I’ll have to learn to like Branching instead.
That said, I hope you pay close attention to your SourceSafe converts as many of our feature needs will center on features in SourceSafe.
Unfortunately, however, this tool does not seem to behave any differently than the Share command in the current Vault client. I still cannot share a root folder to another root folder without burying the shared root source folder under the target root folder. This is the exact problem I described previously.
I guess I’ll have to learn to like Branching instead.
That said, I hope you pay close attention to your SourceSafe converts as many of our feature needs will center on features in SourceSafe.
Last edited by davenovak on Thu Jan 18, 2007 2:14 pm, edited 1 time in total.
Yes, indeed, it does work as you’ve described. Thankfully, the rename and move operation work quickly too, so that’s no big deal. Much appreciated.
But still, one deficiency remains: I must be able to do the share based on a label. As is, the tool always shares the latest version. Would this change be possible?
I must admit, your support here is wonderful, especially given the fact that I have not yet even purchased the product. That said, I’ve requested our IT department to get in an order for 25 Vault licenses ASAP.
Thanks so much for all of your help.
But still, one deficiency remains: I must be able to do the share based on a label. As is, the tool always shares the latest version. Would this change be possible?
I must admit, your support here is wonderful, especially given the fact that I have not yet even purchased the product. That said, I’ve requested our IT department to get in an order for 25 Vault licenses ASAP.
Thanks so much for all of your help.
Honestly, not having VSS-like file sharing is a real problem. I’d be willing to overlook this problem if there was a PowerToy or something that got me around it, but even the PowerToy is lacking the necessary “share from label” requirement that I have.
I hope that there is a plan to somehow remedy this situation in the near future. Users coming from a VSS background will expect this.
One seemingly simple solution would be to allow the existing sharing operation to work on multiple folders & files. In this scenario, the user would
Thank you for listening.
I hope that there is a plan to somehow remedy this situation in the near future. Users coming from a VSS background will expect this.
One seemingly simple solution would be to allow the existing sharing operation to work on multiple folders & files. In this scenario, the user would
- 1. Create a new $/Release 6.1 folder
2. Select the entire contents (both folders & files) of $/Release 6.0
3. Execute a Show Labels… command, which would show any common, inherited labels in the selection
4. Share from the desired label into $/Release 6.1.
Thank you for listening.