In most CM systems, branches are used to collect files for a particular release, to collect files into logical changes, to collect incremental files for a patch build or a custom build, to separate promotion levels, etc. More modern CM systems use branches only, or primarily, to organize revisions into release streams. Other first class objects provide additional collection mechanisms. For example, baseline records identify files for a particular release, changes collect files into logical changes, build records collect incremental files for patch or custom builds, promotion models on changes and build records work with the CM tool to provide dynamic promotion level views.
This difference is significant. In one case, development and implementation of clear branching strategies, labeling mechanisms as well as significant merging activity from branch to branch form an extensive component of the CM task. In the latter case, the first class objects (changes, build records, baseline records, etc.) clarify and simplify the CM task. With proper change management and development stream capabilities, branching can be fully automated, merging reduced to transferring non-shared functionality between release streams and labeling can be fully eliminated.
Product CM deals not only with organization of the CM data, but also with support for generation of the deliverables. This implies creation and/or management of build scripts, configuration management of build tools and processes, and support for deployment of files for the build process.
On a related front, product CM deals with the population of workspaces and the establishment of data views. In some tools, such as ClearCase, these two are intimately connected. Other tools tend to distinguish between the tool view and the user workspace. In these cases comparison of the view to the workspace, and associated synchronization and deployment issues need to be addressed.
Managing Multiple Products
A good CM tool will allow you to track several products in a single repository. This allows easier code sharing and administration among other things. The fact that multiple products are being managed in a single repository means activities, defects, requirements, files, changes, etc. all must be identified with the product to which they belong.
With multiple products, your context (or view) of the repository would typically be restricted based on the product context setting. So if your product context indicated MyProd, you would want to see only problem reports assigned to you for that product. If your tool has the capability, you would be able to select multiple products into your context to see all problems in any of those products. A typical scenario would be when one product is built on top of other products (e.g., third party products). In this case, the CM tool should support a product/sub-product hierarchy. Some systems can be quite complex to navigate and a clearly visible product/sub-product hierarchy is essential.
In a product/sub-product scenario, you will have users that wish to make changes to sub-product files from the view of the product, while others will want to change the same files from the view of the sub-product. The CM tool would need the ability to map these different views onto the user's workspace. Some shops will have two or more separate products sharing the same sub-products. It would be helpful if it could optionally prevent changes from spanning products. If the tool supports automatic baseline generation from changes, it could also support an option to do so in the product proper only or right through the sub-product hierarchy as well.