my  block

where uzairs roam

I’ve had opportunity to become quite familiar with Rational Clearcase in the last year-and-a-bit, including advanced features such as the use of metadata. And having witnessed it first-hand, I have to say that Clearcase’s power is unmatched: it’s an extremely well-considered system that will let you do almost anything you want with it.

Still, power is a secondary concern with source code management (SCM) systems: the first must necessarily be reliability, chased closely by the quality of the developer experience. Since the former is almost assured with modern SCM systems, the latter takes on great importance, and will form the basis of my argument.

Here’s a side-by-side comparison of the developer experience offered by Clearcase and a popular open-source SCM system, Subversion. (The comparison’s also valid for CVS.)

The workflow above is very, very basic. In practice, projects are often in development in several sites. Because Clearcase does many things on a per-file basis, this means replicas of the Clearcase database need to be set up for each site to improve performance. Unfortunately, this is a source of profound pain for developers, with the poorly-implemented concept of request-for-mastership rearing its ugly head. Other basic things that I see developers struggling with include things as basic as reverting to a previous version of a file, for which there is no automatic command. And of course, cspecs, which seem to have gained a mystique all their own. In addition, once the project database reaches a certain size (in my experience, 10GB) performance can be impacted by all the work Clearcase puts in behind the scenes.

Clearcase’s plus-points include the excellent integration it features with both *nix and Windows. On both platforms, it integrates seamlessly by providing its own versioned file-system, MVFS, that makes source control operations transparent. The tool support is also fairly mature and complete, with quality tools for exploring the history of the source code. The merge algorithms used are well-understood and do the job pretty well. (Caveat: XML merging and diff’ing doesn’t work properly. It just doesn’t.)

There is also Rational’s Unified Change Management (UCM) paradigm, which makes a more evolved workflow trivial to enforce and also ties in with products such as Rational Clearquest.

The real gem is the powerful query system, and the way metadata is exposed through the MVFS, giving you a navigable history of each element in the project. This is all available through both a Perl API and command-line tools, so that it’s very common for administrators to implement detailed policies/workflows governing what is and is not permissible behaviour. It’s truly very cool stuff…just not necessarily what is required of a system for source control.

The MVFS, BTW, is often unfairly blamed for Clearcase’s problems. A very senior manager at a Fortune 500 company recently told me that the basic problem with Clearcase is that everyone works ‘on the same file system’. Err…no. That’s partially true for a dynamic view, but since those are deprecated in practice, anyway, it’s not the biggest problem. The biggest performance problem is that too many operations are performed per-file, hitting the database continually.

Having gone from a CVS background to a Clearcase environment, I was initially awed by all the cool things you can do. The fact of the matter, though, is that more often than not, those cool things get in the way, if not as a source of confusion, then as an excuse for over-zealous SCM administrators to build brittle, over-arching policies with. Given the technical and financial requirements Clearcase poses, it’s very difficult to find a reason to choose it over Subversion, or other open-source alternatives.

Additional notes:

• Having used Clearcase both for a simple workflow and in a task-branched environment, I was initially skeptical that Subversion would be able to provide equivalent flexibility. From what I recalled, branching in CVS was a major pain and essentially involved duplicating parts of the repository. Not so in Subversion: you have the equivalent of lazy/delayed branching, with ‘cheap copies’.

• Yes, XML diff’ing/merging is broken. Sure, you can ignore whitespace, but Clearcase isn’t actually parsing any XML you present it, so the merge decisions are far from intelligent. This is true at least up till 2003.06.13.

• Yes, RfM is broken. If a mastered checkout is taken out, there’s no way to unmaster it short of blowing the checkout away. That means that if your colleague’s gone on vacation and you need to work on a file he’s got checked out, you can either blow away their changes (disastrous only with dynamic views) or wait till they get back to. In addition, the Rational Eclipse plug-in randomly makes some checkouts mastered even if you’ve specified in your settings that it shouldn’t. In addition, when you mkbranch a remote branch on a file, if the parent directory is not locally mastered, a generic error message is thrown. In addition, when a branch does not exist on a file and you try to check it out, the mastership check happens before the mkbranch, so you can’t set a trigger to retrieve mastership or create the branch remotely. We got an IBM patch for this, but it only half-worked, and was too clunky to actually use.

• Word is IBM will be switching to a web-based, single-central-repository like Subversion at some point. This is significant, but doesn’t answer why you would choose Clearcase over Subversion unless you’re already using Clearcase.