CM: THE NEXT GENERATION - Don't Let Our Mistakes Hold Us Back

will always be burdened with the following problems:

• When do we switch the main branch from release 2 to release 3?
• What do we do with release 3 changes that aren't ready to merge at that time?
• What happens to release 2 changes that aren't yet checked in?
• How will we define the branching structure to continue to support release 2 after it moves off MAIN and how do we instruct developers?
• What about release 4 changes?  Where do we put them in the mean time?
• How do we make the CM tool clearly show us when the MAIN branch switched releases and which branches are used for other releases at which points?
• How do I have to change my rules for views or context when we switch MAIN releases?

You can probably add to this list.  In a branch-per-release strategy, each release has its own branch.  You always do release 2 specific work in the release 2 branch, and release 3 specific work in the release 3 branch.  Now if your tools support the branch-per-release concept, they will help you.  For example, they will let you know when you make a release 2 change, that it may have to be applied to release 3 or later streams as well.  They will give you the option of automatically inheriting changes to an earlier release to the next and later releases, letting you establish this as a default policy which you need to override when you don't want it, or having you choose on a case-by-case basis.  If your tool has a release stream context for development, it can automatically tell you when you need to branch for reasons of parallel release development, rather than you having to instruct your staff on how to determine when to branch.

The second thing I mentioned was the overloading of the branching concept.  This is because the CM technology did not evolve to support the evolving process.  Older technology may require that you branch code in order support promotion levels.  It may require that you branch code so that you can label it with the feature, the change, the developer, etc.  It may require that you create branches and/or add labels to identify baselines and builds. It may require that you branch code to support short-term (i.e. change duration) parallel changes.  On top of all of this, there's a lot of labeling and merging that results - and unfortunately, that's where the CM technology tends to evolve - to make these tasks easier and less resource intensive, rather than eliminating most of them in the first place. 

Now consider this.  If you were looking at new tools, would you look first at how the tools simplify the entire branching architecture, or would it be more important to you that the tools provide advanced multi-way merging, have multiple ways of viewing branching, or have enhanced labeling mechanisms and a means to catagorize and navigate labels?

If that's not enough to consider, assume your product has been bought out by a new company, or that your development contract does not get renewed and the source code is being returned to the owner, or that one site is being shut down and all of the development code is being consolidated at a single site (without the staff from the other site).  How long will it take the owner to unravel all of the branches and labels that exist in the development environment - even if the CM tool kept perfect track of them all?  The answer here should be, at most, a few hours, not a few