CM: THE NEXT GENERATION of Branching Standards

co-compiled (i.e. have unique names and/or name spaces), and the problem is brought forward to link time, or perhaps even load time.  Files to be linked or loaded are tagged with the feature options so that a build specification need only identify the feature options.  Still, just the process of moving these options forward to link time will result in multiple deliverables that have to be managed, and multiple test beds that have to be reloaded.  So it should be avoided whenever possible.  In any case, the problem is not one which requires the use of branching to solve.  The use of branching for variants comes from the reuse of the same file name for each of the different variants, rather than the use of separate file names to support each variant.  Common code should reside in the common file, while variant dependent code should reside in a variant specific file (i.e.with a file name specific to the variant).

How hard is it to get the design to follow this rule.  Not difficult at all.  The most difficult step, by far, is communicating the rule, and the need for it, to all developers, and then ensuring peer reviews identify violations.  Apart from that, it is a trivial design change, and one that yields way more benefits than just avoiding variant branches.

A Next Generation Branching Standard?
I apologize for the length of this article.  If I had identified additional reasons for branching, you'd see an even longer article.  But it was necessary to justify each of the cases, and if you send me some others, I'll deal with them as well.

OK, you might not understand everything here.  Or maybe you do but you don't agree with it all (please send your comments).  But do you at least agree with the overall philosophy that branching is overloaded?  If you do, then I really, really, recommend you go back to the "motivation" paragraph.  We're not talking a 5% or 10% reduction in complexity here.  No it's more like the difference between Assembly language code and Python scripts.  When branching is simplified, automation increases.

Am I recommending Stream-Based Branching as a CM Best Practice?   Not completely.  Not at this point in time.  It is one way to bring sanity to branching but it won't work for all projects for various reasons.  I know of several companies which have used or tended to this future "standard" for their branching - often with their own home grown tools or scripting.  But I also know of projects in some of these same companies that have stuck with various other branching strategies and patterns.

So why a standard as opposed to a branching strategy or pattern?  Well, a strategy is a good, perhaps rigid, guideline, and possibly even more beneficial to an organization than a standard.  However, in order for the industry to embrace it, a standard is required.  When a standard is embraced industry-wide, in whole or in part, the industry tools can anticipate behavior.  So, for example, if you have to move from one tool to another, your existing branching strategy may not map onto the new tool.  This in turn can turn what might be a few days work into a few months of work.  If the branching strategy is supported across tools, you will not have to limit your choices.  The industry CM tools can also help to automate CM more effectively when specific standards are in place.  It is not a downside that not all CM projects will embrace the standard.  Not everyone uses Bluetooth.  Not everyone uses ISDN.  But for