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

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

Answer 2

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 3

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 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

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.