CM: THE NEXT GENERATION of Branching Standards

1. So that files can be checked in to the repository without breaking the build
2. To support parallel checkouts of the same file so that work isn't held up
3. So that files for a particular Update can have their branches commonly labeled to collect them together
4. To collect and label items for releases, baselines, builds or other such purposes.
5. To identify, easily, the work done by a particular developer
6. To allow back ups of my local work before it's ready to be "checked in" to the main branch
7. To support product variants

We need to do all these things - or at least most of them: work on a different release than the "current" main trunk, have promotion levels, perform parallel checkouts, collect files into changes, releases, builds, baselines, etc., have our local work backed up, prevent pre-mature changes from breaking the build, identify our work, and so forth.  These are all things we need to do.

Branching is a very powerful concept, and a capability provided by virtually all CM tools.  In fact, if branching isn't supported, it's not really a CM tool.  The question is:  Why use branching to do all these things we need to do?  The simple answer is that branching is powerful and, along with labeling, it lets me do all these things.  The real answer is that your current processes and tools are insufficient to let you do these things without branching.  Without branching and labeling, they just don't let you do what you need to do.

I'm all in favour of branching to support parallel releases.  But, quite frankly, in over a quarter century of supporting dozens of companies in their CM practices, I haven't really seen another need for branching.  What I've seen is the need to do all these things - but not by branching.  Instead the use of good process and good tools will suffice while reducing complexity dramatically.

To Branch or Not To Branch
Before going on, I want to refer you back to our eutopia, that is, our recommendation - where we didn't need all sorts of  branching and the CM tools could help automate and simplify life for the developer, not to mention the CM manager and others.  Oh, and let's not forget the technology transfer nightmare that can be avoided by not having 10,000 files, all with different spaghetti branching structures.  No fights about who's doing the merging or when the main trunk is going to switch releases.  This is just the motivation paragraph - to get you to read on.  If you've seen other motivating factors, great - tell us about them, but let's read on.

We're going to evaluate each of these items and determine how branching is, in most cases, easily avoided.  The goal here is not to do a lot of extra work and such to eliminate the need to branch.  The goal instead is to eliminate all the work that is necessary because of branching, while just doing what has to be done anyway.  If you want your CM to move fully into the next generation, this is what you'll have to wrestle with.

So let's look at each branching requirement.

1.  Support of Parallel Releases
This is a real and valid use of branching.  Just make sure the branches follow the product road map (which may change from time to time).  Better yet, let's get the CM tools which make sure they do.

2.  Main Trunk is the Wrong Release
If you're working on a change that's not for the "main" trunk, the tendency is to create a branch for that