Branching Best Practice (Common Library)

baronej · Post by **baronej** » Tue Aug 23, 2005 10:55 am

I have a question about what would be the best practice vis-a-vis branching.

Situation:

I have a common library solution with 15 individual projects (14 dlls and 1 test exe).
These projects are individually consumed by my other solutions. The actual projects used change on a solution-by-solution basis.
While I have shared files/folders in Vault, I am a branching newbie.

Specifics:

These individual dll projects within this solution are used by various other solutions.
The library files are generally broken down by the references they require. I use a third-party component suite extensively, and tend to break out the code in my library solution by which components are required. I.E., I tend to break out the code used by the third-party suite into it's own projects.
I have my library organized as follows in Vault:
$
$\MyLibrary
$\MyLibrary\Trunk
$\MyLibrary\Trunk\Solution -- VS Solution
$\MyLibrary\Trunk\Solution\EaProject -- VS project within library solution
To date, I've been using shared folders instead of linking the projects which consume my libary directly to to the libary.

Problem: The third-party suite I use has gone from v1 to v2.

I would like to upgrade to the new version, but it will require various changes to the libary code as well as the references. I suspect that it will affect about a third of the library projects. The projects which consume my library code will require various code changes (besides changing references) as well.
I also want to be able to have the ability to target the current libary code (i.e., the code targeting v1 of the 3rd-party suite instead of v2). That way, I can leave simple projects well-enough alone if I want to.

Ideas:

Simply add new projects to my library framework version to incorporate the new version, (i.e., copy/paste and rewrite as appropriate) and leave the original code alone. That way everything is guaranteed to be separate, but of course it means that I'm not taking advantage of any branching features.
Develop against the new components on the main trunk (which is set up already), and then create branches in the individual solutions which need to use the original components. This would have the advantage of being easy to implement (since I already have share links to the various consumer solutions, and can simply convert the share links to branches). It would have the disadvantage of creating lots of branches where they are probably not needed.
Branch out the original code to its own branch within the original trunk (as outlined in the best practice KB piece), and then keep developing against the trunk. This would keep everything nice and clean, but I wonder about the file share links. Would I be able to change the share file/folder links to use the branch folder(s) (instead of the trunk) where needed?

I sincerely hope this is reasonably clear. If I'm not, please let me know. And TIA on any help/assistance.

John Barone

dan · Post by **dan** » Tue Aug 23, 2005 2:02 pm

One nice feature of branching in Vault is that maintains shares within the tree you are branching. So, if you have a bunch of shares within $/trunk and you branch all of $/trunk to $/branch, all the shares that pointed to places within $/trunk will now point to their respective places in $/branch, and they will not be shared back to their location in $/trunk. This is done so that any relative shares will continue to work after a branch, and won't change any files back in $/trunk after that branch.

It sounds to me like option 3 is the safest route. After you have everything working again (based on the new version of the 3rd party library), you can invoke merge branches to merge all the work required to upgrade back into the trunk.

Or, you could switch branch and trunk and make the branch the place where the version 1 of the 3rd party software works and the trunk the place where the upgrade happens. Then you would merge branches from the branch to the trunk after the upgrade to move all the changes you made to solutions while the upgrade was happening.

baronej · Post by **baronej** » Tue Aug 23, 2005 2:43 pm

Dan,
Thanks for your answer. It cleared up a lot for me. From what you say, it sounds like this should work:

Create a new branch to hold the v1 code and keep do the upgrade against the trunk.
When I create the branch to hold the v1 code, Vault will remap all the shares so that they use the branch automatically. If that's the case, then I'm assuming that I haven't broken any of my existing projects, since they will be using the v1 branch and not the v2 trunk.
Go ahead and get my library to work with v2 code.
At this point, if I've made any changes to the v1 branch that I would like to merge back to the trunk, I can go ahead and do so.
Start working with whatever solutions consuming the library which I would like to bring forward to v2. Now this is where things get tricky for me. At this point, I have project references which link back to the v1 branch, but I really want them to point to the v2 trunk now. Would I have to completely drop the shared projects, redo the shares, etc. from scratch, or is there some way within Vault for me to simply change where the share shortcuts point to and the do a Get All for me to get the items from the trunk instead of the branch.

dan · Post by **dan** » Tue Aug 23, 2005 3:13 pm

If you branch at a high enough level, the share situation should take care of itself - nothing will be shared between trunk and branch, and you would work in one place or the other until you want to do a merge branches. I don't believe that once you move all your development back to the trunk (v2), you'd have to fix up any shares, unless they were introduced during the time you working on both. Perhaps I'm misunderstanding the issue though?

That said, there is one major caveat to branching that I forgot to mention: If you use Visual Studio integration for your projects, when you branch, every project in the branch will be pointing back to the trunk until you manually fix the projects to point to the new branch. This is a limitation in Visual Studio rather than Vault, but makes for a real pain when branching and using IDE integration. See http://support.sourcegear.com/viewtopic.php?t=1917 for more information on that issue.

baronej · Post by **baronej** » Tue Aug 23, 2005 4:00 pm

I'm using VS (2003) integration.

I have my solutions (which consume the library), set up as follows:
File System:
..\Solution-level
..\Solution-level\Project1
..\Solution-level\Project2
..\Solution-level\Framework
..\Solution-level\Framework\Project1
..\Solution-level\Framework\Project2

The Vault project setup generally follows how I have the project set up, with the "Framework" folders actually being shared from the trunk of the main Framework solution.

I just checked the "Change Source Control" dialog in VS, and indeed they are pointing to the local-level project (e.g., $\Solution-Level\Framework\Project1). So in light of your last post, how would I redo the binding? Can I just change something in Vault and hope VS is none the wiser?

Sorry if I'm not quite clear on what I'm doing. Thanks for the replies so far...

John Barone

dan · Post by **dan** » Tue Aug 23, 2005 4:12 pm

To update the bindings, you'd need to go to Source Control->Change Source Control in VS, and choose the branched location as the new location in source control. This will check out the solution/project files. After changing them, check them in, and it should then be using the new locations in Vault.