General handling of versions, branching, and merging.

twiggy · Post by **twiggy** » Sun Oct 16, 2005 1:47 pm

This is general open question about best pratices. I've read the kb article provided by Vault, but have more questions.

We generally come out with a new version every 4 months or so, and we have to support older versions for quite sometime. Bugs are generally found in really complex situations in our applications, and then have to be pushed to newer and/older versions.

In VSS we went for a style like

/$
application
application_1_0
application_1_2
application_1_3

1.0 was the orginal version, 1_2 the next, and 1_3 is what we where working on. If a bug was discoverd by a client using version 1_0 it generally was fixed 1_0, and then merged to 1_2 and 1_3. When we are done with coding in 1_3 we will rename it to 1_4 and branch it to 1_5. This creates a kind of continual timeline in the branches.

With vault we are moving towards this.

/$
application
trunk
branches
application_1_0
application_1_2

Where trunk is always the active dev version, and the branches have our "stable" versions.

Currently it appears vault doesn't shows the branch relationship anywhere between application_1_0 and the trunk and so forth. Also with this style 1_0 and 1_2 have no direct relationship.

There is no right or wrong answer here, but as a new vault user I'd like to see what users expierence have been.

dan · Post by **dan** » Mon Oct 17, 2005 6:41 pm

It is true that Vault doesn't show the relationship, or enforce it, but it is a bit more flexible, in that you can actually Merge Branches from any tree to any other tree, regardless of whether you originally branched from it. So, you should be able to move changes en masse from the bug fix branch back to the trunk, or from any bug fix branch to any other bug fix branch.