SOFTWARE ENGINEERING blog & .lessons_learned
manuel aldana
Manuel Aldana

March 19th, 2009 · 12 Comments

Reasons NOT to use ClearCase

After 3 years of working with ClearCase SCM tool I came to the point that you should not use it for developing software. Surely it has its moments: The branching and merging capabilities are good and the graphical version tree is nice. Also the concept of the config-spec, which is a kind of query-language for an scm-configuration (the set of checked out artifacts) is powerful. But there also many shootout reasons, why it is bad.

No atomic commits

Once you checked in files it is very hard to revert to a certain state, because atomic commits aren’t supported. When checking in multiple files, each file gets a new revision (similar to CVS) and not the check-in itself. I think this is a crucial feature, because you hardly want revert single files but complete commit actions (which should map tasks). With ClearCase you can only revert to certain states by using Labels. In practice using ClearCase Labels for each check-in is overkill and thus not done.

Crappy user interface

The GUI of ClearCase Explorer is just a big joke. Horrible in usability and ugly looking. Different and often necessary functions aren’t provided (e.g. recursively checking in worked on artifacts). Command line tool cleartool used with cygwin is much better, but still some things aren’t available like recursively adding new files/folders to source control. I have to laugh my head off if I read a 50 lines of code long script to workaround this.

High administration efforts

Administrating ClearCase beast is far from obvious or lightweight (in difference to other scm-systems like CVS, subversion or Git). Expect to put quite a few dedicated ClearCase experts to just keep it running.

Horrible performance

Nothing is worse as making your developers wait while interfacing with SCM-tool, it is like driving with hand brakes enabled. It slows down your brain and also your work. Getting fresh new files to your snapshot view takes around 30 minutes for 10K artifacts. An update (no artifacts were changed) for the same amount takes roughly 5 minutes. When experimenting a lot and jumping between different up-to-date views means a lot of waiting. It gets even worse, when you’re working on files and you want to check-in or update them. Check-out, check-in and adding to source control cycles take around 10-15 seconds which is obviously a nightmare. It gets very annoying when you’re refactoring renaming/moving types or methods (many files can be affected).

Lack of support of distributed development

Today software development is often a distributed thing (developers are spread around the world working on the same product/project). ClearCase definetely isn’t suitable for this, because it is badly suited for offline work. Doing a check-out (action before you can edit a file/folder) requires that you are network connected. Here you could use the hijack option but this is rather a workaround as a feature (you basically just unlock the file on the filesystem). If your development sites are far away from your ClearCase server the check-in/check-out latency can even increase so dramatically that it is not usable at all. There are workarounds for that like using ClearCase Multisite (scm DB replica technology), but you have to pay extra for it and is not trivial to adminstrate.

Git as alternative

Though being a big fan+supporter of Open Source I am still willing to pay money for good software. But looking at IBM-monster ClearCase I wouldn’t invest my money here, it has all these discussed shortcomings, and further more IBM doesn’t seem to invest money to improve their product significantly. Recently I had a look a Git scm which looks very good, especially for its branching+merging features, where ClearCase has its major strengths.

Tags: Technologies/Tools

12 responses

  • 1 McHalls // Mar 20, 2009 at 9:57 pm

    I am not a CC fan, but u stated some not fair reasons.

    No atomic commits
    True, no support for that. However, in most cases you dont even need that. When u merge from branches, even without labeling u can be on the safe side and rollback to a previous state.

    Crappy user interface
    Depends on taste of course. Recursive checkin in fact exists, but its not that simple as it should be, I agree. Of course u have CLI on native windows too, u dont need cygwin for that.

    High administration efforts
    I agree, though its usually 1 person is enough even for larger projects.

    Horrible performance
    Interesting, the volume of slowlyness u mention, I never crossed. Usually its fast enough not to even recognize the chechout/checkin. If its configured properly, u should see no such bad performance.

    Lack of support of distributed development
    Well, snapshot view is your friend if u need offline work. Honestly, what do u expect from a tool, when u r offline?

    U say its bad that hijacking simply takes off the readonly flag, but u should be happy about that. Its simple, u dont even need CC to do that an it works.

    Imagine u have a local repo and u do checkins and a lot of stuff – what do you exactly gain having the repo locally? U need to merge in the end and thats what CC is doing and thats what other tools do too. U have no choice.

    Again, not a CC fan, but other tools are sooo lame in GUI interfaces and especially in merging, that they are simply not suitable for larger projects. No wonder that larger companies use commercial tools. If there would be an open source alternative that would be even close to what CC offers, CC would lose a lot of customer. But there IS a reason why it is used in so many places.

    Also dont forget that CC customization is possible and CC is not only a version handler tool. Others are.

  • 2 admin // Mar 25, 2009 at 1:51 am

    I like atomic commits on every checkin, because then rollback of work tasks is much easier. Especially when doing refactorings I do lots of iterations and need this rollback of code states often.

    Snapshot view is “more” offline as dynamic view. But still you need to be connected for checkout, when you’re working on files. Hijack for me is not an option, because I want to use the version control locally and track my changes. With distributed scm-tools you can work completely offline with all the usual scm-features. Here you work on your “personal” branch for your work tasks and then merge to the public.

    Lucky you that you never had performance issues with CC. But I guess that it is far from trivial to tune it properly in a distributed environment (most of the problems seems to come that its protocol sits on top of network shared drives). Other scm online-environments (e.g. subversion over WebDAV) tend to handle things much better. No matter where I downloaded subversion sources over the world from it was quite quick. I don’t want to know how it would have performed when these projects used CC…

    You’re right that the branching/merging features of CC are showstoppers on most projects. That is why you should not use CVS and subversion, where merging can be a big pain (especially if you move nodes around). Therefore I am looking to Git these days, from talks and articles it solves most of the shortcomings of CC and offers good branching/merging features. It also has been proven for big codebases. It is used for linux kernel (which is >10MLOC) and many open source projects which are fed up with subversion adopt it.

  • 3 Garen // May 28, 2009 at 8:00 pm

    clearfsimport has been around for a long time and be used to import a lot of files into CC, although it’s not built into a context menu in CC Explorer. It is now in CCRC though.

    Never had any big complaints with CC performance. If the project was large, simply used snapshot views.

    Config-specs are a usability problem, and without atomic commits it’s hard to implement CI, which is my main complaint with CC.

    And if I was going to use one of the new DVCS systems, I’d use Mercurial–which actually _works_ on platforms other than Linux. I don’t really care if git can run in 0.01 seconds rather than 0.1 for an operation I do once an hour.

  • 4 Arbeitsverhinderungstool ClearCase : Zustandsforschung // Jul 9, 2009 at 10:48 am

    [...] Features von ClearCase kann man in den beiden Artikeln ClearCase, making easy things hard und Reasons NOT to use ClearCase [...]

  • 5 SayNoToClearCase // Jan 28, 2010 at 5:37 pm

    The ability for developers to define ANY config specification in their development environment allows a dangerous form of mixing/matching branches/tags/timestamps of files in a view.

    In a team of multiple developers, this results in the game “Who Has The Real Config Spec Defining The Tip Of Development”. Developers WILL try to workaround the merging/tagging system in source control to grab code from here, there, and everywhere in the repository by tailoring their config specs.

    If you can’t define what the actual tip of development is, then you have no releasable product. No releasable product means may well induce contractual penalties when the related project misses its delivery dates. I’ve seen this situation nearly cost past employers millions in undelivered projects due to the ass-clownery that results.

    This kind of obstacle also makes an excellent political game of “eliminate the developers and manager from the non-delivering project”.

    Avoid jobs that require the use of ClearCase: it may just save you being laid off due to the ensuing politics.


  • 6 Nicam Energy // Apr 17, 2010 at 11:35 pm

    I have learned that these negative posts are submitted by incompetent and troubled people, both developers and administrators.

    I give you on piece of real example.

    I have just started a new job in the city, the organization is using ClearCase.

    You have no idea of the disgusting job the person that left has done.

    Do no take it to the tool, kick in the arse those incompetent pricks.

    You know the most ridicule fact? They paid that Muppet more than me.

  • 7 Nicam Energy // Apr 17, 2010 at 11:39 pm

    @SayNoToClearCase, I have a question for you.

    Have you re-read the post before you submitted it?

    You are a living contradiction my friend


  • 8 monty // Jun 9, 2010 at 9:18 am


    You have no idea what everyone talking abt. please take some rest

  • 9 IHateClearCase // Mar 9, 2011 at 3:11 am

    Another late night messing with ClearCase. It is the biggest steaming pile of s#$% software I have ever used. I spend more time dealing with ClearCase than writing code. It is absolutely ridiculous. I am an engineer with 17 years of experience and have used perforce, subversion, and others in the past. You would think any other SCM would be intuitive to me at this point. Well, no… I spend hours pouring over the ClearCase docs and still end up scratching my head. I’ve been dealing with ClearCase for a year now and I am the point person on my team for it. After a year of working with it, it is still completely unintuitive.

  • 10 IHateClearCase // Mar 9, 2011 at 3:14 am

    It is incredibly slow. It does unexpected things. The simplest tasks are made to be unbearably difficult. Eclipse integration sucks.

  • 11 Eazy // Jun 16, 2011 at 11:54 am

    Actually, SayNoToClearCase has a very valid point “Who Has The Real Config Spec Defining The Tip Of Development”… Granted clearcase has some benefits, but overall, you have to understand that developers (those who use the tool everyday) are the people you want to listen to.. And tbh, I haven’t seen a good word about CC yet. I work in finance IT and as far as I know, two large IB’s are getting rid of it.

    Companies make money on delivering software, not managing it – that should be an easy and intuitive task. In fact, one of the only things you should have to worry about, is when am I going to branch?

  • 12 Reed Shilts // Jan 29, 2012 at 11:06 pm

    Big thumbs up!
    I went from a Perforce project to a ClearCase project. What a joke – Perforce had its shortcomings, but ClearCase is an impediment to performing a “core competency” like “what files were checked in _with_ this file”.
    And needing a full time administrator – give me a break. This is a TOOL to support the development people – needing an admin is so 1970’s.

    A recent rant of mine….

Leave a Comment