CM: THE NEXT GENERATION of Branching Standards

but we really need to look at it closely this time:  The use of the branching capability is terribly overloaded.  And it is terribly overloaded because our processes and tools don't address the real set of CM problems head on.  We're going to explore this in more detail, but first, let's do some "dreaming".

A Simple Stream Branching Recommendation
Let's say branching were done only to support parallel release management - at most one branch on each file per release. Simplistic?  Perhaps, but I don't think so.  In fact, for the last 30+ years I've said "I don't think so".  On 2 person projects, 20 person projects, 200 person projects, 2000 person projects - this is a concept that needs to be embraced.  You might not be convinced - so tell me the problems with it after you've read the rest of this article.  I'm sure we'll generate some intense discussions.

To start, assume branching were done only to support parallel release management.  Well then, here are the recommended rules for the branching strategy from this perspective.

1. Products, Directories, Files may all have branches
2. Product branching follows the product road map of releases (i.e. product branches, a.k.a. release Streams)
3. Everything else follows a subset of the Product branching layout.
4. Branching is never done to support a variant.
5. Change Requests (ECRs, Problem Reports, Tasks/Activities, Requirements, etc.) are targeted to a specific release Stream.
6. A change package, or Update, as we will refer to it for clarity, is authorized by the approval of a change request.
7. Each Update is targeted to a specific product release, i.e. the Stream of the Update.
8. Files are checked out against the Update which collects all of the changed/changing files together.
9. When a file is checked out, if there is no file branch for the the Update Stream, one is created (and labeled with the Stream)
10. If there is a file branch for the Update Stream, a new revision is created along that branch.

So, whether or not you agree that this is a feasible approach, we now have a branching process that has several very interesting properties not always seen in a project.

• The branching strategy is easy to learn. In fact, the CM tool set can automate it.
• There is a simple naming/labeling convention for any branch: it's Stream name.  No manual labeling should be needed.
• All files have the same branching layout - which is a subset of the product road map of releases
• Technology transfer of the project does not involve a long analysis of the state of current branches and resolution of them.

Context
Now let's go one step further.  If I want to work on a particular release of a given product, all I should need to specify is the Product and the Stream (and perhaps a promotion level, but we'll get to that later).  The CM tool should be able to infer everything I need to know from that simple context specification:  Product + Stream [+Promotion Level].  

If I need to know what's on my To-Do list, the tool should present me with the list of items based on my context.  If I need to check out a file for which there is no branch in the context Stream, the tool should be able to look at the product road map and determine which stream to pull (and in this case branch) the source code from.  If I'm just retrieving (as opposed to "checking out") a file, the same rules apply.  The CM tool knows what the branches of each file mean because it has access to the product