CM: THE NEXT GENERATION of Branching Standards

may be checked out for additional changes to be made by the same or a different developer, without the instance of forcing a parallel Update which would later have to be merged, as the new Update can be performed on top of the first developer's changes.

5.  To support parallel checkouts of the same file so that work isn't held up
We've just seen one example of how branching for a parallel Update can often be avoided.  More commonly, parallel changes overlap more than just at the "waiting" stage.  Some shops disallow parallel Updates, as a rule, to eliminate the extra complexities in process and testing.  They enforce exclusive checkouts.  While this is an admirable goal to simplify process, it can cause significant delays.  An approach such as the "ready" promotion level can help to reduce delays.  

An additional approach, whereby an Update is broken into multple less complex Updates, all tied to the same Change Request, can further reduce the need for parallel Updates or exclusive delays.  For example, it is common that a few "header" files which define message codes, run-time id's or other frequently expanding definitions, have significant checkout contention.  When the checkin of the addition of one message code has to await the completion of the related feature, there's a significant chance of change overlap.  By breaking the change implementation into multiple Updates, with the first Update just adding the message code, and perhaps a stub function to handle it, the chance of overlap can be significantly reduced.

Even after all of these process improvements, there may still be the need for somewhat frequent parallel Updates (or delays if we take the exclusive checkout approach).  So this is when you need to branch to support parallel check outs, right?  Not quite.  Your Update has already announced your checkout to the CM repository.  For the vast majority of such changes, there's really no need to create a parallel branch as well.  After all, your workspace holds the file until you're ready to check in your Update.  If there are multiple users with Updates in parallel, this does not signal the need for parallel branches.  

In fact, some tools and processes which otherwise require parallel branches provide a means of subsequently removing or hiding such branches because they really add nothing to the CM history, and only serve as placeholders because, either the tools don't support some form of change packaging, or because even though they do, they don't allow parallel checkouts without branching.

I'm all in favor of minimizing the need for parallel checkouts.  I'm even in favor of those companies which, having minimized the need, find it acceptable to use only exclusive checkouts.  Often that strategy will even improve software design, forcing the design to minimize contention.  But if you are going to do parallel checkouts, other that for parallel release changes, I would be very reluctant to recommend branching to accomplish it, even to the point of suggesting an exclusive checkout solution.

6.  Files of a particular Update can have their branches commonly labeled to collect them together
For most CM tools, either they don't really support change packaging or such a concept was added on late in the game.  Some of these tools and processes require, if you want to collect files together into an atomic Update, that you simulate the change packaging by creating a branch for each file of the Update and labeling it with the Change Request or, even better, the Update identifier.  The branching is done specifically to support the labeling.  The proper implementation of change packaging using