CM: THE NEXT GENERATION of Branching Standards

additional data, add a database to your tool or switch to one that can provide the data mechanisms out of the box.

9.  Back-ups of local work before it's ready to be "checked in" to the main branch
Now here's a valid requirement.  My work is on my workspace, on my laptop.  I'm making changes daily and it's not getting backed up, or if it is, it's distributed over 300 other desktop and laptop backups.  It'll take hours, if not days, to identify where the backups are and to recover it if necessary.  So the solution is to put it into the CM repository.  Then it gets backed up in a common place whenever I want.

But if I want to back up my work nightly, I'll have to put it into the repository nightly.  That means, in some tools, I'll have to check it in nightly.  That means lots of revisions being created.  Of course I'd want them in a side branch and not in the main branch of each file.  So this must be a valid use of branching.  But not so, even if your tools and processes don't allow you to do nightly backups otherwise.  Many CM tools allow you to "shelve" your work so that you save the current contents without creating new revisions of the file, or perhaps creating new revisions that are not visible.  The latter case may cause some performance issues though.  But either way, your CM tools and related processes should allow you to save your Update-in-progress without having to clutter up the CM information, and especially without having to create branches, even if they're "temporary"

10. Variant Handling
So many projects start out as a one of, and then split off into dozens, if not hundreds, of variants of a product.  Managing large numbers of baselines, builds, etc. is not only tedious and resource intensive, but it's risky.  Sooner or later you're going to reach a point where you can't cope.  I've seen it more than often enough.  The "solution" taken is typically branching and labeling and still the problem persists, but now as organized chaos.

Variant management is primarily a software engineering problem, not a configuration management problem. Your team must specify Design Criteria which will make CM manageable.  CM should not attempt to solve software engineering problems which are rooted in the design - though it may help you to identify them - and variant handling is one area where software engineering needs to be addressed by the design.

It is not difficult to avoid dozens of variants.  In fact, it's much, much easier to reduce variant programs into run-time options and configurations than not to do so.  Introduce a simple design rule that a variant will not be a build time variant, or a load time variant, if it can be a run-time variant.  Whether it's a sizing option, a language option or a set of feature configurations - you can create separate images that support each of these.  But you can just as easily add a requirement to the design team that says, the size will be configured at run-time by setting a Size parameter, language through a run-time Language setting, etc.  The main valid reason for variants to be handled in the CM process is different platform support - and this reqiures separate executables for each platform - but should never require branching.

In extreme cases you may be space constrained and can't load all of the 100s of options into one image.  In this case, options should be handled as separate files which can be