CM: THE NEXT GENERATION of Quality in your Configuration

you have to branch to create promotion lineups, to identify short term parallel checkouts, to collect files into a change or to define a baseline or build definition, you'll likely have a lot of labelling to do as well, and a lot of scripting to help automate that labelling.  Preferably you have underlying technology which can deal with baselines, builds and changes as first order objects.  And preferably you have technology that can compute views and deal with parallel checkouts without forcing
unnecessary branching into the picture.  A runner-up capability might be one that helps those branches disappear when they no longer add value to the CM repository.

Automated Branching.

Your CM repository is tracking all of your development branches, where they've evolved from, etc.  It also knows the branching information for each file, directory and ideally the product as a whole.  It should let you share unmodified code from earlier streams in a later stream and let you inherit changes from the earlier stream automatically if you so
choose.  If your branching is well structured, your CM tool should be able to tell you at checkout time whether or not you need to branch and should also identify the branch point for you.  It should be automated - no branching strategies to learn.  You shouldn't even have to look at the file revisions when you do a checkout operation.  There should be
enough information in the CM tool to allow this to happen and that's been the case with the tools I've used over the past 20 years.  And to go one step further, because the CM repository contains all of the history, it should let you know when you make a change to one branch that may have to be applied to other branches.

Baseline trees vs collections.  
As an added benefit, and going back to change based CM, branching of directory objects (assuming your tool supports these) should be automated.  The changes are defined in the set of software updates you've prepared.  You should only have to request a new baseline from the root (or any subtree for that matter) and new revisions of directories should be created according to the updates.  In some cases, directories may have to be branched. A tree-based baseline structure integrated with a change-based CM system can eliminate all manual directory branching decisions and tasks. If your baselines are defined simply as a set of revisions with directory specification stored against each, rather than through a revisioned file tree structure, this may be difficult to accomplish.

Configuration View Flexibility.  
If you have to define a baseline in order to navigate a configuration, you're very limited in your configuration view capabilities.  Many tools allow you to specify what's in your view without having to create a baseline which defines that view.  In cases where the specification is rule-based, the view changes as the data changes. You can even go
one step further if your CM tool will automatically show you your preferred view based on your context, without you having to specify any rules.  Your tool should let you wander from one configuration to another as necessary, to look at the contents of a specific build, to
view parallel development streams, etc.  The quality of your decisions are going to be only as good as the quality of the information you're viewing.  And if you're looking at an "almost the same" configuration because its too difficult to look at the actual one, you're asking for
trouble.

Stream-Based Main Branches.

Many of you have had debates over what's better, a single main branch or a main branch
for each persistent development stream.  Although a single main branch may seem simpler, it breaks the rule "as simple as possible, but not too simple".  As a result, the process required to support a single main branch is much more complex, introducing