Sometimes the smallest change has the largest effect. This might be the case with clearcase; a simple change in policy could improve productivity disproportionately. One of the areas that can have great impact is Configuration Management.

Primarily this document focuses on the Unix based products. It identifies improvements the way that clearcase- the version management software- is used. This document aims, however, just to set out the ideas as an argument for change.

Minimal Branching
A common feature in software version management is the ability to branch. This allows the creation of separate code-streams such that separate versions of software can be worked on and maintained independently. Complexity arises when the same change needs to be performed on multiple branches. Merging does this. Traditionally, within version management- with systems like CVS- this would only occur for maintenance or refactoring.
The hidden cost of Merging
Merging can be expensive. The larger (in terms of lines) the merge the more room for error. Another opportunity for error is that merging is performed in isolation from the actual development; when the work is done it should be merged and merging to synchronise later can cause problems, as the original intention of a change can be unclear: even with bug branches.
Minimal Branching Principle
To keep development simple, therefore, there should be the minimum amount of branching. That is there should only be a branch for a new code stream that is going to exist in parallel with another. Branching on a feature basis overcomplicates things because:

  1. It encourages isolation rather than co-operation. It is naïve to assume that release features for a release can always be viewed in isolation. More often than not there is commonality between these features, which results in cross-branch merging between feature branches at the time of development.
  2. It increases development complexity, as developers must have an idea of what exists on each branch. While this is relatively simple once the feature is written during development the state of completion of each branch needs to be understood. This extra complexity often means that at least one developer is needed per branch. There is an implication here that is related to Section 4, one developer might keep the state of each branch in his head but at the expense of what? With something as transient as a branch it is unlikely at any one time there is more then a few people who know the contents. The more developers on a project the more complex it becomes.

By reducing the number of branches the merges are kept small and localised (the merge done by the feature developer at the time of development), merges would generally occur at check in.
With this said there is justification for branching.
So where is branching used? Table 1 gives the reasons for branching.
[table=tables-professional Branching Function | Justifcation
Release Maintenance | Once a release is produced a maintenance branch is produced at the point which the next is to be started. This needn't be at the point of release. The release itself is labelled with the release label. If branching for release development does not occur then maintenance of the previous release could continue on main until design were complete.
Refactoring | Occasionally a component may need completely reworking introducing a substantial amount of new software. Justification for branching here is based on if the work is larger than other release components and is unlikely to make the imminent release. This is an exceptional case as refactoring should be incremental.
Research/Prototyping | Sometimes, even with the best design in the world, it is better to try a solution by prototyping a new design or architecture. In this case this code may never make a release. Needless to say prototype code will need some reengineering before integration into a release. Branching, like with refactoring allows for the achitecture to be reworked but also prevents hacks from every being released. ]

Related to minimal branching is the idea of Component Revisions.

Regular Builds
By producing regular builds and expecting them to break during development of a release provides useful information about the state of release development and whether the release is running late. The output from the build can be merged with information about the files that had been modified since the last build to produce a list of people/teams responsible for breaking the build. Some open source initiatives use this technique by publishing the information on a web page so who's is the responsibility for build failure can be attributed to those people who changed the code.
Although this might be helpful in the management of a project, during normal development it primarily provides developers with the name of their peer so that they can work to resolve build problems.
The organisation of regular building should be organised by the use of deadlines. The configuration specification for a regular build should use a date selector. This excludes all check-ins after a certain time from the build. Goals can be then set to get certain pieces of development checked into the build by a build date.
Regular building fits well with the idea of iterative development that is a recognised technique for risk reduction. These builds can be packaged up before the release date and installed. Minimal Branching is relevant, but not essential, in that the less branches there are the fewer builds that need to be performed regularly.

Clearcase Tips and Tricks
Clearcase even with UCM can be a beast to administer. You should ask yourself the question: Do we really need it? If you do use it though there is a whole new world of exciting administration ahead of you.
There is an art to writing makefile, this is expecially true if the makefile are used accross architectures. Say for example the same source code is compiled on a later version of a particular architecture. It may be that there is little or no code change. The same VOB is used. What can happen is clearmake will wink-in derived-objects between the architectures. If the config record is the same then it must be the same object.