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.