Skip to main content

ClearCase, or is it?

I'm not sure the case is that clear with this one.

Disclaimer: I'm by no means a ClearCase Guru. I'm just someone who strongly believes source control management (SCM) systems should be perfectly usable by people who are not their admins. ClearCase begs to differ. After using it for almost a year, I'd like to beg, though not to differ, but for someone to put me out of my misery.

It all began with installing ClearCase on my workstation, which required 0.5-1 hours and a ClearCase admin instructing me what to do over the phone. Once I started working with it, I could not help but thinking I was the tool and ClearCase was the user. I expect tools to relieve users of certain liabilities, not introduce additional ones. Guess I'm just funny that way.

Perhaps ClearCase has many great features, but it seems to fall short when it comes to the standard, mundane operations carried out daily. Frequent VOB communication errors get in the way of the most basic operations like checking files in and out, making your interaction with the source control slow and frustrating. I'm not sure who's this VOB guy, but it has lots in common with a typical teenager.You have trouble communicating with it, you get yelled at for not having permissions to touch his stuff (or files) and you often hope he'll grow up already and behave.

Working offline was especially challenging as I had to manually remove all the read-only attributes ClearCase so diligently puts on all files it manages (it might as well have pissed on the files to mark its territory). Perhaps it's also worth noting that some of the continuous integration procedures might not be too happy with this read-only attribute trick as well.

Although I had a ClearCase plugin for my IDE (VS 2010) I was unable to find a clever way to automatically detect new files that had been added to the solution and needed to be added to the source control as well. All new files had to be hunted down one by one, and manually checked in.

Another fun fact is that updating your view does not affect your checked out files. It would have been nice to get a message saying "Listen, I know you just did an update but since you have this and that checked out they have not been affected". This piece of information is crucial since you don't always remember what's checked out and when performing an update you can be easily fooled into thinking you have the most recent code, whereas actually - that might not be the case at all.

Merging is a potential pain no matter what source control you use, but ClearCase brings it to a whole new level. The merging workflow requires a great amount of steps which are hardly intuitive and often take a while. It's a shame that a procedure that is nontrivial by nature, has unforced, extra difficulty added to it. In fact,  I'm still trying to figure it out, and have learned some new words like rebase, recommend and synchronize stream. Now all that's left is to also learn their meaning.

What seems to particularly characterize most ClearCase workflows, is the lack of a streamline. There're so many options, so many buttons, dialog boxes, confirm prompts. Finding the right one often feels like being a mouse in a maze, trying to find your way to the promised cheese.

In a way, going from SVN to ClearCase feels like going from C# to C. Perhaps there're cases where its power shines, but there're so few of them, and you really need to know what you're doing. I bet many (if not most) people will never get it to shine, they'll just feel lost and frustrated trying to accomplish the simplest of tasks.

In the end I did find a great benefit of ClearCase - it made me appreciate SVN a whole lot more.


Since ClearCase encourages users to check files out in reserved mode, only one developer can work on a given file. This can often be ineffective, especially in teams working closely. One might try checking files out without reserving them. However, this can result in an even worse scenario. If while you're working on an unreserved file, someone else checks this file out in reserved mode (which he can, since you haven't reserved it), you will not be able to check it back in until it gets unreserved. Now imagine you're refactoring, and have made changes across multiple files. When you try to check all your changes back in, some get in, while others fail since they got reserved by someone else in the meantime. The bottom line is, your codebase gets updated with only part of your changes, while the rest is left out, on your workstation.
Congrats, you are now playing the "will my codebase compile when only a portion of my changes got checked in" game, be careful though, as the looser breaks the build.


Popular posts from this blog

Sending out Storm metrics

There are a few posts talking about Storm's metrics mechanism, among which you can find Michael Noll's postJason Trost's post and the storm-metrics-statsd github project, and last but not least (or is it?)  Storm's documentation.

While all of the above provide a decent amount of information, and one is definitely encouraged to read them all before proceeding, it feels like in order to get the full picture one needs to combine them all, and even then a few bits and pieces are left missing. It is these missing bits I'll be rambling about in this post.

Dependency Injection - The good, the bad and the ugly

The Good
Dependency injection (DI, a.k.a IoC - inversion of control) is a well known technique to increase software modularity by reducing coupling between modules. To provide the benefits of DI, numerous DI frameworks have arisen (Spring, Guice, Castle Windsor, etc.) all of which essentially give you "DI capabilities" right out of the box (these frameworks tend to provide a whole lot more than just "DI capabilities", but that's not really relevant to the point I'm about to make). Now, to remove the quotes around "DI capabilities", let's define it as a DI container - a sack of objects you can manipulate using a provided API in order to wire these objects together into an object graph that makes up your application.

I've worked on quite a few projects employing Spring, so it will be my framework of reference throughout the rest of the post, but the principles and morals apply just the same.