Anthony Borton links to a post by Michael Ruminer on “Recommendations in SCM Branching Patterns in TFS“. I’ve obviously got my own views on this subject so I thought it would be interesting to read Michael’s post to see where our strategies differ.
The funny thing about branching is that there are some universal truths, the first is that no matter how you draw up the diagram, its always a tree. In that respect, Figure 1-3 and Figure 1-2 in Michael’s post are largely the same. Another truth is that the longer you are away from the trunk, the harder it is going to be to merge – and in this case, time is determined by the number of changesets applied on both branches.
One thing that I like to do with branching models is ask them questions, for example, in the model that Michael has presented, how would I start v.Next feature development when I am feature complete on v.Current (about mid-way through the graph in Figure 1-3).
At the end of the day, each branching strategy is designed to solve 80-90% of the concurrent development problems of a particular team or project. You probably aren’t going to get a 100% solution, but the beauty is that there are so many approaches to pick from.