Versioning example using branch

[travisb]

Could someone give me an example of the steps needed to do versioning with Vault 2.0? I've never used Vault at all, and my company has just recently purchased the product.

Here's a scenario I'm looking for:

I have a project which has been completed - version 1.0. I'm moving on to version 2.0, but I need to fix some bugs in version 1.0, so I need to make a version "1.1" before 2.0, and will most likely want to merge those fixes into 2.0. What steps do I need to take? Can all this be accomplished with labels? Would using branches/sharing be more helpful?

Additionally, I have a question about branches. I read the example of branching basics in these forums which discussed the red and blue teams and the refrigerator with beer, etc. It seems to me that when you use branching you are creating files/folders with different paths but with the same history. If that is the case, then don't you have to update any references in your project to those files, since their paths have now changed? I'm still a bit confused on the uses of branching I guess.

[sterwill]

This was originally a reply to a duplicate request posted by Guest in the Support forum, which I've deleted in favor of retaining the one with your name.

Here's what I'd do using Vault 2.0. Different developers will have different preferences. Some really like labels, some really like branches, some may have an alternate strategy involving shares and branches.

We'll start off assuming my repository named "Project X" has the following structure:

Code: Select all

$
 + trunk
 |  + src
 |  + docs
 |  + ...
 + branches

$/trunk contains all of my source code for Project X, and it's now time to release 1.0. When I've done all my testing and I'm ready to ship, I create a label on $/trunk and call it "1.0". In Vault 2.0, labels don't appear in the repository structure, but any time I want to see them, I can just click on $/trunk, and choose Show Labels. $/branches is an empty directory at this point.

It's the day after 1.0 shipped, and I've got some good ideas for what will go into version 2.0. Knowing I've created a label for 1.0, I can just go ahead and start working in the trunk again, adding my new features that probably contain lots of bugs and will require testing soon.

But then a user reports a big nasty bug in 1.0 that I have to fix, and quick. So I perform "Show Labels" on $/trunk, find the "1.0" label I created, and select "Branch $/trunk" from the menu. When the dialog pops up that asks me where I want to place the branch, I select $/branches, and type in "1.1" as the name of the folder to create. When I click OK, a new branch of the trunk folder is created as $/branches/1.1.

Since all of my source code (including project files) is contained inside the trunk folder, I can just create a new folder on disk and set it as the working folder for $/branches/1.1, do a Get Latest Version, and start fixing my bugs.

When I ship 1.1, I can label it, or not. Personally, I wouldn't create a "1.1" label on the 1.1 branch, since all my cool features are being developed in the trunk and nothing will change in the 1.1 branch from here on. When it's time to fix that one bug I didn't find in 1.1, I'd just branch $/branches/1.1 into $/branches/1.2, make a new working folder, and repeat. If you created a "1.1" label, you could branch from there, too.

This process is similar to the one SourceGear uses for its own development (which is done with Vault, of course). Hopefully this helps answer your second question (about paths). If you chose to label and then branch subfolders inside $/trunk (maybe only $/trunk/src/gui/client was ready for 1.0), you'd need to update any project files in the parent folders to point to the working directory where you retrieved the branch. Of course, you could move the old one out of the way (rename it), retrieve the branch, and keep working that way, if your project configuration would allow this.

[travisb]

Cool, thanks for the reply. It works great!