Basic ClearCase Usage Theory

This section is dedicated to the theory of using ClearCase. It is not a how-to section. That will come later. It is strictly a theory section on how you might be able to use ClearCase on your site as a Configuration Management tool.

Development and Branching

Aren't You Suppose to Avoid Branching?

There is a common mispreseption that branching is supposed to be avoided at all costs. This myth developed when users of other Source Configuration Managment tools started using ClearCase. In those tools, branching is difficult and should be avoided. In many of theses tools, branching is reserved strictly for parallel release development. Mainly to fix bugs in an older revision while you work on a newer revision. Most of the time, you never have more than 2 or 3 active branches in a project. Branching is hard to do, and is usually kept to a minimum.

ClearCase is different. Branching is done in order to provide work areas for development. It isn't unusual for a site with ClearCase to have dozens of branches active at a time. Branching in ClearCase is easy to handle. ClearCase branches are named and not number. Branching can be created automatically, and tools are built with in ClearCase to track branches. Branching is actually central to ClearCase's power.

This is not to say that there won't be a situation where branching isn't necessary. But those situations are very rare in the ClearCase world. The major problem sites have in using ClearCase is the lack of branching.

Attempting Not to Branch

The diagram represents the element tree for foobar.c. At this site, all development work is done directly off of /main. At this site, versions that are ready for the system build and testing are labeled. Notice that some versions of foobar.c aren't labeled. This could be due to the developer checkpointing their work or for other reasons. The developer has labeled foobar.c@@/main/3 with REL1 because it is ready to be tested.

Testing REL1 of foobar.c will take a few days. Since the developer has other work, the developer rechecks out foobar.c and continues with development. Meanwhile, an error is discovered in version /main/3. But, by the time the error was discovered, the developer had already done extensive work on foobar.c.

Standing By and Twiddling Your Thumbs

There are several solutions to this problem. The first is to prohibit the developer from doing any more work on the program until testing is complete. As you can imagine, this is not acceptable to most sites. Having a resource as expensive as a programmer doing nothing but cruising the Web for a few days is simply not acceptable. It is expensive, and it delays the project.

Another solution is to make the programmer hurry up with the changes they are doing on foobar.c@@/main/5 and fix the bug there. Of course, the programmer might not be close to a stopping point. In other words, the tester might have to spend a few days cruising the Web waiting for foobar.c to be completed. There is also a good chance that the latest version of foobar.c will have more bugs that were introduced since /main/3.

It may take a long time before a new version of foobar.c actually passes testing and is ready to be included in the next build. Meanwhile, other programmers may be waiting for a version of foobar.c in order to continue with their programming. In desperation, many sites simply implement the first strategy - prohibit the programmer from doing any more work until testing is complete, and the bugs are all fixed.

Playing Leapfrog

The other solution is to check in /main/5 as /main/6, check out /main/6, copy /main/3 into /main/6, check /main/6 back in as /main/7, and have the tester check that. Meanwhile, the programmer will checkout /main/7 and copy the data back in from /main/5. This is called leapfrogging. If it sounds confusing, it is. Imagine attempting to track down the version history. A change made in version /main/5 disappears in /main/6, but mysteriously reappears in /main/8.

The Real Solution

The final solution is to create a branch, fix the error on the branch, and then run the test on the change on the branch. In the diagram below, /main/3 is checked out onto a branch called rel1_bugfix. The bug is fixed on /main/rel1_bugfix/1 and tested. Meanwhile, the developer can continue their work without playing games. If the testing proves good, then foobar.c@@/main/rel1_bugfix could be accepted into the next release.

Development and Branching - As the Rule

As shown above, branching was the cleanest way to handle the problem. It allowed the developer to continue their work without waiting for testing. When a bug was reported, it could be quickly fixed, and a new version provided.

However, if branching is the solution, then why not make it part of the development environment in the first place? Let's assume that instead of branching as an accident, branching is incorporated into the project from the beginning. Let us examine the same situation as above, but with a particular branching strategy incorporated from the start.

At this site, a similar foobar.c is being developed. However, at this site, each programmer is given a branch for development. /main is only used for versions that are ready for release. This is not the only branching strategy that can be used, but it will show how branching can solve development problems before they start. Again, this is not a HowTo guide, but a guide simply explaining ClearCase theory.

In the above diagram the developer has created a new element called foobar.c. However, instead of doing any programming on /main, a branch is created, and all development work is done on /main/al. The developer is finished with his work and it is ready for testing.

The developer has renamed the branch from /main/al to /main/test. The developer then creates a new /main/al branch and copies /main/test/3 into it. While the developer is waiting for testing of the version of foobar on /main/test/3 to finish, the developer continues their work on foobar.c.

An error is detected on foobar.c@@/main/test/3. The developer corrects the problem right on the test branch creating foobar.c@@/main/test/4. This doesn't interfere with the work the developer has done since foobar.c was tested. Since the fix to foobar.c was done on /main/test, no further errors were introduced.

In the above diagram, version /main/test/4 of foobar.c has passed testing. This is placed on /main and ready for the next release. Changes from /main/test/4 can be merged to /main/al/LATEST once all other work is on /main/al is completed, or if the changes made in /main/test/4 are small enough, these changes can be made manually onto /main/al.

Once an approved version of the file is placed on /main, /main/test can be renamed to /main/test_feb_3_1998, and locked as obsolete. Locking the branch as obsolete still keeps the branch /main/test_feb_3_1998, but allows the branch to be hidden from view when required. If for some unlikely reason, changes on /main/test_feb_3_1998 must be made, the branch can easily be unlocked and modified.

Meanwhile, once the programmer finishes his work, he will again rename his branch from /main/al to /main/test, and start the cycle all over again. With this branching strategy, neither the tester nor the developer were forced to wait. An approved version of foobar.c is already to be used for the next build.

Take a close look at the above diagram again. It looks a little confusing since there are three branches used and several merge arrows. However, the flow of work was still very smooth. Although the diagram is fairly complex, the views needed for it are very straight forward:

ClearCase View	ConfigSpec
Developer's View	`element * /main/al/LATEST`
Tester's View	`element * /main/test/LATEST`
Release Manager's View	`element * /main/LATEST`

This is not the only way branching can be done, nor is it necessarily the best way to use branching for a particular site, and may not necessarily be the way your site will be handling branching. However, it should be clear that branching in ClearCase is not something that should be avoided. In fact, there are some general rules that can be used for ClearCase:

No development work takes place off of /main
This reserves /main exculsively for completed versions of the software
All major development takes place on branches
Merging can be done from not only from the development branch to the release branch, but also from the release branch onto the development branch. This is called back merging, and back merging allows a programmer to take care of most of the merge problems on the development branch before placing the new development onto the release branch.