Mature Branching Plan – A Question on Branch Hierarchy

  • Article

Question:

I have a request from a customer regarding the Branching/Merging Model in TFS 2010.

The customer has the following branch model: Main->Rel. A -> Rel. B ->Rel. C -> Rel. D.

Today (TFS 2008) it is practical impossible to Merge D->Main without going through back to C,B,A with the change sets.

The /baseless merge does not help so much in this scenario.

Will this be changed in TFS 2010, I did not find anything like “any node”->”root”  Merge in the documentation, so I assume the answer is no ?

Any guidance beside the  branching guide ?

Answer:

If you follow the Rangers Branching Guide II in Codeplex (https://tfsbranchingguideii.codeplex.com/), you will notice that we recommend that EACH release branch be a full branch of MAIN. As you correctly observe, having an unlimited number of levels in the branch plan for an unlimited number of releases becomes very cumbersome. To avoid having to merge D back to main without merging through all of the prior releases, all release branches (A,B,C, and D) should branch directly from MAIN.

There are so many reasons why you want Release A,B,C,D to each branch from MAIN. The goal should be to have each release be independent of each other. If you look at the Advanced Branch Plan in the branching guidance, you should find a three-level release plan (Main->ServicePack->Hotfix->Release). When you are ready to ship a release, you create these three branches at the same time. Once shipped, the Release branch (at the lowest level) is made read-only for safekeeping. Subsequent to this, you may service the release by making changes for a specific customer in the hotfix branch. If desired, these changes can be merged back “up” (Reverse Integration) to the Service Pack branch, and the Main branch where they can become part of future releases.

Later, when you are ready to ship Release B, you follow the same process. Create another set of release branches (Main->ServicePack->Hotfix->Release).

In an earlier post, I have an illustration of a mature branching plan (both logical and physical view). This the structure I would recommend for your multiple release model (https://blogs.msdn.com/billheys/archive/2009/08/14/mature-branching-plan.aspx)

Bill Heys