In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
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 versus 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 sub-tree 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 revised 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 it’s 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 artificial dates for starting and ending a stream's tenure in the main branch. It also requires three different processes for dealing with a development stream: before, during and after it's tenure as the main branch. Stream-based main branches are simpler: one main branch per stream means the process for that stream is always the same and there are no artificial start and end dates. This