CM: THE NEXT GENERATION: Configuration Management Planning

for your software updates.  If your tools only support file-based operations, your developers will be checking in files one at a time, associating each file with the task, building delta reports by piecing together multiple file deltas, doing promotion file by file.  And so forth.  Change-based operations need to be central to your CM Plans.  If your tools don't measure up, change them so that they do.  File-based operations might cut it for small programs involving very infrequent changes, but even there the manual effort is going to lead to quality problems.   Check-in should be a single change-based operation, as should promotion, delta reporting and traceability linkage.  Get your developers out of the mode of looking at files and revisions, and into the mode of looking at changes.

This is an essential directive of a CM Plan.  It is not optional.  File-based CM will give you quality problems and overhead that you will not be able to handle in any reasonably large project.  In effect, you will end up adjusting your tools to compensate for the fact that you don't have real change-based CM.

How Does Your File Branching Map to Your Product Road Map
Your CM Plan has to address your branching structure.  This is a difficult issue.  Many CM Managers are familiar with the way CM worked in their earlier projects, and the efforts taken to ensure that it would work, because of its fragile nature.  But most CM Managers will not look into why CM is fragile.  Branching architecture has a lot to do with it.  A predictive branching architecture is one where tools can both help you with the branching reqiurements, and easily, and automatically, navigate branching history as necessary.  An ad hoc architecture may seem to work, but you're not going to get a lot of help from your tools other than providing you with a labeling mechanism, which if used improperly, could bring the project to a halt.  So let's look at branching in more detail so that your CM Plan can give some good direction.

In software, it's easy to make a copy of something and change it.  When two or three developers do this in parallel, it is known as a parallel change.  When a project needs to develop release 2 of a product while supporting release 1, this is known as parallel development.  For new releases, parallel development means creating parallel copies, known as parallel Branches, of software files when implementing new features.  Fixing problems may or may not result in parallel copies.  If you want the fix in both releases and the files being changed have not yet changed since release 1, you can fix it in release 1 and get the fix for free in release 2, at least if your tools and processes allow this.  Some tools will have you clone your entire product for a new release, forcing you to make the same fix in two (or even multiple) places.

Parallel development is a valid reason for creating a new Branch of a file.  Parallel changes generally are not a good reason (with exceptions).  The reason many tools and processes suggest parallel branches for parallel changes is that they don't have a mechanism to track the fact that changes are going on in parallel.  The update mechanism should support this without the need for creating and tracking parallel branches.

Branching is often used for keeping track of feature development, for grouping file revisions based on promotion level (i.e. highest test status attained), and for numerous other reasons.  Branching is a powerful concept. In fact, that is precisely