CM: THE NEXT GENERATION of Quality in your Configuration

you:

• Who is the primary owner of each data record
• How do products relate to/depend on one another
• How do I find the source tree for each product
• What is the development history for the product

Now this list could go on forever as many requirements spawn data schema requirements.  But some of these are more crucial to the simplicity of the user interface than others. Given the development history for the product, the CM tool can recommend to the user where branches are to be branched from. Given owner information, data can be restricted or presented in the user-preferred order more easily. 

Basic CM Process

If you want to really want to simplify and automate the CM function, you need to have your process reflect the what is being done and you need your CM tool to capture the data needed to support the process and it's automation. Here are a number of ways your process/tool combination can help.  Not all of these capabilities will be possible with all tools, but maybe someday...

Change-based CM.  

The industry already agrees this is good.  But it's more than good - it's crucial. You will not be able to build a successful CM tool with file-based CM.  You need to be able to track changes and change files only against these changes.  The changes themselves will contain the traceability information necessary to interact with the rest of the ALM functions. 
Select changes for a build, roll-back changes, add changes to a baseline, propagate a change from one development stream to another.  If you're doing these operations on a file-by-file basis, you're on shaky ground and the day will come when you put half a change into a release and your customer pays for it. If your IDE plug-ins work on a file-based mechanism only, you'll need your vendor to improve them or you'll need some extra steps in your process to help ensure that changes are properly defined.

Change Context and Change Dependencies.  
One step better is to ensure that the change contains adequate information so that it can flow through the system automatically. The change context identifies the product and development stream for the change.  This is vital to ensure that the correct changes are delivered to the correct build teams and processes.  Ideally, this context information is automatically added to the change based on the user's working context. Change dependencies will be both implicit and explicit.  The system can identify implicit dependencies based on the order of file revision changes.  The user can add explicit dependencies to ensure that changes are delivered in the right order, where necessary.

Change Promotion.  

Branches are overused.  If you're using branching to define your change promotion model, you could be doing better.  Unfortunately few tools support context views based
on change status (i.e. promotion level).  If you have one of those tools, you will simplify your branching structure and eliminate a lot of branching, merging and labelling activity.

Changing Tree Structure.  
Adding files and directories, moving files to new directories, removing files from the tree.  These are examples of changes. Rather than being made in the source code, they are made to the directories.  And just like source file modifications, a change may also have tree structure modifications.  If your tool tracks these great, you're way ahead of the game.  If your tool allows your to specify these changes without having to manually checkout and create new directory revisions, all the better.  Because when you have to create the directory revisions, you're implicitly introducing a dependency on change order which
probably would not otherwise have to occur.

Reduce Branching and Manual labeling.  
Branching and labelling run rampant in some CM processes.  The reason is that the underlying tools have a branching mechanism, but no other mechanisms to deal with the requirements of your process.  If