The Lurker

Irrational

From Rational Wrapup: Two Days in Orlando, a post about Rational's developer conference:

The accelerating adoption of decentralized source code management tools like bzr, git, and Mercurial by projects like Ubuntu, the Linux kernel, and Mozilla/OpenSolaris respectively is confirmation that the demand for tools that allow geographically disparate teams to work more effectively together is high. Even if, strangely, most of the conference attendees I spoke to hadn't heard of this trend.

Couple this with what was apparently some sort of slogan or theme for the event – "What keeps me Rational?" – and it's hard not to imagine that the only reason anyone sticks with Rational software is ignorance of the alternatives.

I mean, check out the comments on Joe Gregorio's ClearCase as a leading indicator of small technology company failure post from 2004. You can divide the comments up into a handful of categories:

• ClearCase is terrible
• ClearCase is better than Visual Source Safe
• I'm a ClearCase administrator, and I think it's great – so long as you don't use UCM, or the GUI tools, or Windows (!) ...

Notably, the challenge in the original post – hopefully with someone from at least one small technology company that has succeeded inspite of deploying ClearCase – went unanswered in the comments (unless you can count I wouldn't say it's been an unmitigated disaster as an endorsement).

Nearly three years after that post, ClearCase has remained stagnant, but an impressive new generation of source code management tools has emerged – git, Mercurial, bzr, as mentioned above, being the most successful among them – and using any one of them for even half an hour shows exactly what is so profoundly wrong with ClearCase. Perhaps, even just three years ago, it was true (as some of those comments by the ClearCase administrators assert) that there was no more powerful a tool available. But – and even if that were true, I would argue that, more powerful or not, it was still a worse tool than Subversion or even CVS, for one big reason I'll come to in a moment – these new tools are so far beyond what ClearCase can achieve.

I've had to use ClearCase at work for a little over five months now, yet I can still be surprised by its quirks and failings. Just last week, Kevin tried to check in a new file but omitted a space from his checkin comment, which meant that a ClearCase checkin trigger rejected the comment, causing the checkin to fail. Fair enough – the purpose of the trigger is to reject checkins which lack a comment identifying the feature or work request for which the change is being submitted – but what we discovered next was inexcusable: an empty file was checked in, and his snapshot view was left in an inconsistent state. This should never happen. There is no excuse for a failed checkin to modify the repository at all.

That's a very unusual case – and I'm willing to entertain the possibility that the problem could have been avoided, for example, if the trigger had been implemented in a different manner – but it highlights one way in which the ClearCase model is fundamentally broken. A more everyday occurrence is highlighted in this ClearCase cheat sheet, which explains the following process for adding a new file to the repository:

• Check out the directory containing the file
• Add the file
• Check in the directory

Note that these are three distinct steps the user must perform to get the result that the user expects. In comparison, essentially every other system uses these two steps:

• Tell the system to track the new file
• Commit the file

Not only does this require fewer operations, there's a very substantial difference between this approach and the ClearCase approach: it does not involve operations on the directory containing the new file. All of these systems work by having the user identify files to be tracked, and (when the user requests it) logging changes to those tracked files. Until the user commits the changes, nobody else can see the state of the tracked files.

ClearCase, however, is fundamentally different. Consider what happens when a new ClearCase user (someone who is familiar with one of these other systems) mistakes the ClearCase mkelem (the "add the file" step above) for the "track this file" operation (like add in CVS, Subversion or Mercurial). It is very common in those systems to add new files before they are in a finished state, or even as soon as they're created (and, interestingly, the ClearCase plugin for Eclipse encourages the user to add files when they're created too). If you haven't checked out the directory containing the new file, that directory in the central repository will end up in one of the following states (depending on which mkelem options were selected):

• an empty file will be created in place of the new file; or
• the new file will be published with its current (and generally incomplete) contents.

Now, again, I admit that this scenario is unquestionably a case of user error. But I note that of the two outcomes, it is very likely that neither outcome represents something the user could conceivably want. In fact, I have broken our CruiseControl build doing this accidentally, and have seen a number of other first-time ClearCase users on the project do the same thing – something that has very inconvenient, productivity-killing consequences for the entire development team – until somebody taught us the "check out the directory first, and don't check it in until your new file is finished" trick. It is just incredible to me that something as fundamental as adding a new file requires a "trick" of any sort.

There a number of these quirks that I've stumbled across since I started working with ClearCase, and I've found that in almost every single area where ClearCase diverges from the practices followed by the other version control tools I've used, the ClearCase approach is unquestionably inferior. (The only feature I've seen in ClearCase which is neither obviously bad nor matched by other tools' capabilities is its config spec, but even that appears to exist to handle ClearCase's quirky branching model. To the extent that config specs are useful, Subversion's svn:externals property supports similar outcomes, and CVS sticky tags can produce a similar effect, but neither is as straightforward as the ClearCase config spec.)

Even once all those tricks and quirks and traps have been encountered and overcome, there remains one great fundamental flaw in the ClearCase approach to version control. Fundamentally, in my not so humble opinion, the purpose of a version control tool is to identify change. Yet ClearCase requires you to manually tell it what files you're going to change. This is inexcusable. Literally every version control tool I have ever used other than ClearCase automatically identifies changes to every file you tell it to track – and, when you retrieve new changes from other users, they tell you which of your modified files have been affected. ClearCase, on the other hand, not only requires a checkout operation for each file you modify (and each directory where files are added or moved), but it hides from you any changes made to files you have checked out. While it's possible to manually ask ClearCase to check for changes to your checked out files (either by examining the history of each file in turn, or by using the appallingly slow "Merge Manager"), in practice it's quite likely that the first time you will discover that somebody else has superseded the version of a file you were working on will be during a checkin – meaning that some of your files are published to the repository, and some of them aren't, leaving the repository in an inconsistent state that will very likely result in broken builds for the entire team.

It amazes and disappoints me that Rational has been so successful selling a product that is not only substantially outclassed by every single competitor I've ever seen, but for a staggering price when most of those superior competitors are free.

Related topics: Rants Mindless Link Propagation