Does ClearCase fit our development process?

Question

So, let me describe our current situation. We are a small team (6) of experienced Java developers, lost in a big IS team that is composed in majority with SAP and Siebel configurators.
While all the other teams were currently using VSS, mostly as a vaulting system, our team had switch for Subversion (after evaluating DVCS as well) as it best fits our agile methodology.

Now, everyone is asked to move to ClearCase, and all the migration effort is put on the VSS users as they are the biggest part of users.
As we are left on our own and don't know really ClearCase, we have some fear that it won't fit our current work process.

Here is currently how we are working on a daily basis:

• SVN repository follows the /trunk, /branches, /tags structure.
• Each developer has its own sandbox in the repository, for testing and prototyping purpose.
• We intensively use branches for new feature development, and are used to merge them together to do some integration testing before promoting them back to the trunk.
• Working in Java, we are used to do refactoring, and Eclipse is a great help for that. A lot of classes and packages renaming is done everyday.
• Depending on how the projects evolved, some pieces may be reused, resulting in a split of a project in several project, the original remains integrated through the svn:external property.
• We use keyword substitution for some elements as it's a extremely simple way to know for the tester what revision he's testing.
• Our Subversion repository is linked to Hudson for running test suites and promote valid builds by tagging them.

All that I know about ClearCase for the moment is that we'll have to use it through CCRC (or via its eclipse plugin version), and that it is highly encouraged that we linked most of our projects to a ClearQuest project for issue tracking management.

Could you enlighten us about how well ClearCase will substitute our Subversion, what concepts have an exact match (I don't care about synonyms but really about concepts), and what kind of changes could you foreseen in the whole process.

Thanks.

Answer 1

First, here are a few posts you could read about ClearCase:

• What are the basic clearcase concepts every developer should know?
• How to Leverage Clearcase’s features
• ClearCase advantages/disadvantages

Now:

• CCRC means "web views", i.e. snapshot views on a ClearCase-dedicated web server... you better have a good LAN between your desktop and that server.

• branches are first-class citizen in ClearCase, meaning one given ClearCase view (here a snapshot ccweb one) will only give you access to one branch. If you are used to working on several branches at once, you will need several views.

• all operations are file-per-file, so the idea on working on a private branch, then merge is cumbersome because of the number of merges involved.
  I strongly recommend working on a common branch for a given development effort that several developers want to address.
  If they want private branches and sandbox, they can setup a Git view within their ClearCase view without problem.
  (Note: a snapshot view cannot be considered as a sandbox: when you check-in a file, every other developer will see your changes when they will do an update of their snapshot view)

• the ClearCase Eclipse plugin does support refactoring.

• the notion of svn:external is not really supported in ClearCase, except through links. Or through UCM baseline dependencies.
  One should be aware that it is easier to work with binaries dependencies than with sources dependencies: if your external is for including the thousand of source files of the next project, it will be cumbersome in ClearCase (due to long updates). If you include a few jar or dll, that is much quicker (plus those are the one which will actually be deployed).

• If you are working with UCM, it will not be possible to move codes from one component to another. You will have to clearfsimport the main labels in the new identified "common" component.

• Note: RCS keyword substitution is generally considered... evil ;) I would recommend a separate text file with the version or labels of relevant important files in it. That works fine for delivery materials, not for source files.

Answer 2

Clearcase is a powerful Software Configuration Management tool and most of the things you outlined as your daily activities are possible via Clearcase.

Clearcase has the concept of views which is akin to sandbox you have mentioned. With some basic knowledge of configuration specification (set of rules to pick versions of elements from the repository) it is easier to do branching and there is a good support for merge of changes done in different branches.

One activity of which I am not sure whether it is supported or not is the keyword substitution. Even if Clearcase support doesn't keyword substitution, you can create a pre-checkin trigger to do keyword substitution automatically.

But It is not clear to me whether all your interaction with Clearcase will be only through CCRC (Clearcase Remote client) alone. I have not used CCRC and don't know what all things are supported via CCRC.

Answer 3

In my opinion, CC is a bad choice for agile team. In principle, you'll be able to work with it, but you'll inevitably lose you productivity to some degree. Amount of that degree depends on how good and sympathetic are your CC administrators. They must clearly understand needs of development team.

In our team we have really bad times with CC. Our admins are remote and isolated from the rest of the team, so we are forced to communicate with them through mails and request tracker. You can imagine how much time it takes. We cannot upgrade to latest CC versions due to expense and complexity of this process (and some administrative burden, I guess). So, we use CC/CCRC of 7.0 versions.

CCRC of this version completely sucks. You cannot easily refactor with it. You cannot perform arbitrary merge with it. You cannot create baseline. You cannot even put files to list of ignored. By the way, as far as I know, CC supports ignored files only in latter CCRC versions and not in native CC client. Our CCRC version has no command line interface at all.

CC highly depends on server communication and for this reason CC (and CCRC) leaves developer on its own when he tries to work offline. CC repo is not usable remotely without CCRC or remote desktop (mouse click response time is of the order of minute).

CC interferes with other tools because it marks all files as read-only and requires them to be explicitly checked out before modification. So, having Eclipse plugin you are able to refactor. But with any other tool you are out of luck. You'll need to check out files before or to modify them forcibly, thus turning them into hijacked. Having you use another IDE, sed or awk scripts or something alike you'll get problems. And even if you only use Eclipse, operations involving CC (that means all rename refactorings etc.) are slow because CC is slow.

The only good thing about CC is that it is good at merge and merge tracking. But Subversion 1.5 got rather close to that point. And anyway, it doesn't buy me into using CC.

I admit that my sharp negative opinion is mostly formed by my personal bad experience. But I'm assured that even in ideal CC setup with perfect process and administration, your productivity would anyway suffer. That's because of CC's over-dependence on server and "Check out-check in" with strict locking approach. It provides some "work-arounds" (I'd rather call them kludges) to this like unreserved check outs and hijacked state but they add their own problems. CC constantly stands between you and your code.

And by the way, I guess that IBM Rational will sooner or later move their customers to Jazz platform. Its Rational Team Concert is something with "agile flavor". It has free edition for 10 developers and some integration with CC (but not sure if it is free too). So you could give it a try. I don't believe in anything good from IBM Rational, though.

Answer 4

Gizmo,

I am currently going through the same problem as you, except from the other perspective - I'm a ClearCase admin attempting to migrate a team away from SVN into ClearCase.

CCRC is being touted as the tool to use in order to develop Java. I'm not entirely sure I believe that - CCRC (The ClearCase Remote Client) has been designed to assist developers working remotely from the main infrastructure. Code is saved to the desktop in order to assist in access speeds - but there's an overhead of checking in and out that can't be ignored.

Refactoring is technically possible from CCRC, but is not possible to do refactoring if disconnected from the infrastructure - the tool won't let you.

There are also other issues with Eclipse Workspaces fitting in nicely with CCRC Views - you may (depending on the branching structure of your environment) have problems with absolute pathnames for tools.

Something to bear in mind - and to perhaps look into - is that ClearCase does do vanilla snapshot views. I disagree with VonC (for perhaps the first time ever, he's one helluva admin) in that I believe CCRC views (which are called web-views) to be quite different from native snapshot views which allow you to develop in an environment alot more like SVN - especially if you are looking to do Java Development.

As for ClearCase and Hudson, I've talked with Andrew Bayer to get the ClearCase plugin working a bit easier with Dynamic Views - which came into play on the 0.9 release. He's quite an active member of the Hudson community, so if you have problems with the plugin, raised issues should get fixed pretty quickly.

Biggest advice I can give though is that just because it's different, doesn't mean it's worse. Be patient, you'll be surprised at the level of control ClearCase can give you if you read the documents and take your time.

Good luck!

Stuart

Answer 5

Here's the issue with ClearCase:

ClearCase was created back in the 1990s when your workstation on your desktop system might not even have had a disk drive -- let alone space. Plus, your desktop system was probably memory limited and slow.

ClearCase was a great answer. Views could live on a view server. VOBs live on a Vob server. Dedicated machines that are fast, fast, fast.

ClearCase had derived objects that could be winked in instead of having your slow machine attempt to compile the code. What a time saver that was!

And, ClearCase's VOB structure meant you could do things that few version control systems could do. For example, you could cd into a file if you appended @@ on the name. That allowed you to see all the branches, tags, and all versions of that file. You could simply run your standard Unix tools to search for differences, etc.

Then, the world changed:

• Desktop systems got more powerful. You have the diskspace, the memory, and the raw processing power. Creating a checkout workspace on your local drive (and you certainly had one) meant you didn't have to depend upon the network which was getting slower as more and more network processes appeared. Wink in a derived object? Heck, my machine could build the sucker five times faster than ClearCase could locate an appropriate derived object.

• Windows. ClearCase was designed with Unix in mind. Hooks could operate on the local system because everyone had Perl installed on their desktop, and you could easily make sure they all were at the same revision. Heck, you could have an NFS mounted /usr/local directory (I know, but networked local directories were common) with the right version of Perl or whatever installed, and your hooks would work. Windows didn't play so nicely. Hooks became a headache.

• Windows again: ClearCase depended upon the Unix tools to work well. Windows didn't have them.

• Agile Development: When ClearCase was developed, the development model was one of isolating developers from each other. You could work a lot faster if you didn't constantly have to worry about another developer making changes to your system. In ClearCase branching was easy. You could give everyone their own branch, and then they could merge back to the main branch when they're done. Merge back and forth! It's easy in ClearCase. Heck, UCM is built upon the very foundation. Unfortunately, the strategy demanded complete discipline. You had to keep reminding developers to merge their code, so other developers could see them. There was the inevitable merge crunch that occurred right before a release as dozens of developers all try to merge their changes back to the integration branch. Agile development removes the concept of developer isolation. You make small changes, and keep track with what others are doing. Thus, the concept of "Oprah Branching" (You get a branch! You get a branch! Everyone gets a branch!) is no longer used.

• So, now you have a fast system with plenty of disk space and memory. You can have three or four separate checkouts at once. The dynamic view advantage simply didn't overcome its disadvantage of being dog slow and network intensive. Snapshot views help, but they remove all the ClearCase magic one once had. In other words, why use a system as big and as bulky as ClearCase like it was CVS when you could just simply use CVS in the first place?

• Lastly ClearCase is hard. Back in the old days when developers were all system and network experts, learning the ins and outs of ClearCase could be expected. Making views was no harder than learning YACC syntax. However, developers aren't as system savvy as they once were. Why should they be? You don't need to know how memory works in order to program in Java or C#. Developers no longer want to learn about 100 different tools in order to do their job. ClearCase training can take a few days, and learning the ins and outs of ClearCase can take weeks. In ClearCase, I have to understand the view syntax to do simple things like modifying code on a branch. With CVS, it's just a single command.

ClearCase simply is too complex, slow, and expensive. And, much of it was the bet that Atria took when they built ClearCase: 1). Developers will be willing to learn it because they have to learn 100 other tools anyway. 2). Your desktop machine is slow and tiny compared to the network servers. Doing everything "in the cloud" is faster. 3). ClearCase centralization abilities is a great advantage for companies since one site can manage and support everything.

All three of those assumptions turn out to be false, and because of that, fewer and fewer companies are even considering ClearCase. Maybe back when Rational bought PureAtria, if Rational brought it into the 21st century to make it smaller and lighter and cheaper, it might still be a widely used tool. But, Rational was too busying making development more convoluted in order to integrate all the nifty tools they bought into a centralized development process. By the time IBM bought Rational, ClearCase was starting to bleed users.

Answer 6

clearcase is most powerful versioning system I ever know. All enumerated tasks are supported.