Migrating from Rational ClearCase

I participated in a webinar two weeks ago, Subversion in the Enterprise, in which we had a limited chance to respond to questions. We’ll answer some of the remaining questions here.

One topic that came up multiple times was enterprises migrating from Rational ClearCase. Since I spent 5 years helping sell, implement and support ClearCase, and now 6 years at CollabNet, I understand both worlds pretty well.

Before focusing on ClearCase though, I encourage you to read some very good migration articles that can be found in the Subversion migration project. I talk to big companies every day about Subversion and many of them are considering to migrate or have although done so. These articles are a good start to prepare for a migration.

When planning a migration, the most important thing you need to do is realistically determine what data you really will benefit from migrating, rather than just assuming you want to migrate everything. For one thing, you don’t want to clutter your new repository. If you move from one house to another, you have garage sales, donate items to charity, and throw things away. The same concept should be applied to version control migrations. What really do you need in your new “house”? Realize that you have to pay the moving costs for whatever you migrate so be sure that the value you realize is worth more than the cost.

I always suggest leaving historic data in the legacy tool and just taking the latest from the live branches or perhaps snapshots of key milestones from current development branches. You should minimize your investment in the legacy tool both in terms of licenses and hardware, but retain it as the historical archive. A potential alternative is to migrate the historical data to its own Subversion repository while migrating limited data into the “production” repository. That way, history is retained (with the clutter stored elsewhere) and the legacy tool is eliminated along with its licensing and support costs.

Any migration will have limits based on the differences between the legacy system and Subversion as well as the extent to which the migration tool’s author(s) decided to map functionality and metadata between the two tools. With ClearCase, it is not a question of “will there be limits?”, but rather how many limits. ClearCase doesn’t really support data migration so the development of migration tools is very challenging. That said, I am aware of at least a couple of attempts at providing such a tool. The first was a tool developed by an enterprise specifically for their needs and situation. It had limitations that they were willing to accept but the tool will unlikely be acceptable to most other companies.

Most of the focus these days is on the SVN Importer tool which purports to support migrations from many different version control tools. Unfortunately, a brute force approach – limited to a full migration – is taken to ClearCase and to most of the other systems. Such an approach requires a lot of system resources (e.g., disk and memory) to execute. That has proven itself to limit the size of a source VOB that can be migrated using a relatively “average” machine. One customer has seen that limit at a 150MB VOB, but the limit will vary depending on the hardware used for the migration. This customer had one VOB larger than the tool could support but fortunately they wanted to split the VOB contents anyway so they split it and executed two migrations resulting in two Subversion repositories.

As for case studies of enterprises successfully migrating from ClearCase, I certainly see it happening, particularly with companies that are truly doing distributed development and those who don’t need the unique features of ClearCase. Some companies have migrated history but most are leaving it behind. In my experience, the biggest key to success is not to recreate ClearCase processes in Subversion, but rather revisit your organization’s version control needs and map Subversion’s features and proven best practices to meet those needs.

Keep in mind that companies usually run a pilot before making a commitment to something as critical as a new version control tool. When they commit, they do so based on their own documented experiences. For a migration from ClearCase, I highly recommend you do a pilot first. After that you can join the companies that are enjoying the many benefits Subversion brings over ClearCase, such as atomic commits, real support for globally distributed development and consistent performance with tags and branches.

If you need help with your migration, our Professional Services team has a lot of experience helping customers move to Subversion. Check out our corporate web site for more information.

Bob Jenkins

Bob Jenkins has spent over 17 years focused on application life-cycle tools. At CollabNet, Mr. Jenkins consults with enterprises that are planning to adopt Git or Subversion on how to apply best practices to their SCM processes. He aslo helps define the areas of investment by CollabNet in open source version control tools.

Tagged with: , , , , , , , , , ,
Posted in Subversion
9 comments on “Migrating from Rational ClearCase
  1. Attila Vágvölgyi says:

    Big enterprises do not like to move first. Usually they leave piloting risky moves to other big enterprises. Less people are fired for not making decisions than for making bad ones.
    Could you list some well-known examples for companies who decided to migrate from ClearCase to Subversion? It would help small people to have arguments fighting with the status quo.

  2. Rupesh K Prasad says:

    Hi Bob,
    I am trying to migrate a 10 yrs old Rational ClearCase Repository to Subversion.
    The size os the repository > 1GB. I have tried with SVNImporter tool. But it seem to be running
    for weeks. And at completion when I imported the dump into SVN, I couldn’t see any files there.
    The size of the dump was in MBs whereas the imported repository’s size in SVN was in KBs and
    further both the repositoties are on different machines and different envitonments
    i.e Clearcase on Windows and Subversion on SUSE Linux.
    Could you please suggest some solution in this regards. I am a total newbie to this activity so if the commments are to extreme details then it will be of great help.
    Hoping to hear from you soon.
    Thanks a lot in advance.

  3. Bob says:

    Hi Rupesh,
    I haven’t had any personal experiences with SVNImporter so can’t really be of much help here. Customers have not reported your experience to me. They’ve had situations where the process failed after running for days due to resource limitations, but I haven’t heard of an empty dump. Did you look at the dump file itself to see what it contained (frankly a dump file of MBs vs GBs after running for weeks and on a repository with 10 years of data sounds small)? And the load operation completed successfully, but just didn’t put any data in the repository? I’d start by confirming the dump file and then if that seems alright, then I’d look at the load process.
    You might want to see if you can post your issue on the SVNImporter project to see if the developers or other users have advice.
    Good luck!

  4. David says:

    I hoped to find some practical advice on how to do it – how to export, how to import, how to change labels/baselines to subversion tags.
    There is non of these in thsi article – just generic bla bla.

  5. Bob says:

    The practical advice is to avoid taking history as it isn’t an easy or foolproof process to do otherwise. You were pointed to a tool to use if you wanted to try and migrate history so that was specific and practical. As to taking snapshots, the process is quite straightforward if not time-consuming.
    You need to determine which snapshots you want to take over (potentially labelled versions for example) so you know the order and can determine the execution steps. You start with the oldest snapshot and establish access to it via a ClearCase view. The config spec may have to have a rule selecting the label, but also a rule to get the other files/dirs that were not labelled yet would be part of a Subversion tag. The initial snapshot can be imported into Subversion (svn import) likely to the trunk and then a Subversion tag applied indicating the same information as the originating ClearCase label.
    Subsequent snapshots are taken in time-based order with the ClearCase view established as with the first one. Now the process requires that you do a comparison between the ClearCase view and a Subversion view that exposes the latest revision on the trunk. This is so you can identify and execute deletes/moves/renames on the Subversion working copy to match what happened in the ClearCase view. Once you’ve done that, you can copy the ClearCase view (minus any ClearCase specific objects – e.g., lost+found) onto the Subversion working copy. You then commit indicating that you want to add any unversioned files in the working copy. Again, tag that revision to match the ClearCase label. Repeat this process until complete.
    BTW, blah has an ‘h’ at the end.

  6. rao says:

    It is good artical.but there is no clear procedure for using svnimporter to migrate from cc 2 svn.

  7. Bob says:

    Since we don’t really recommend full migrations, we aren’t really experts in the execution of the svnimporter tool so can’t give you a clear procedure for its use. You might try the users@subversion.tigris.org mailing list to see if someone there can relate details about their use of it.

  8. Alan says:

    Where is the rest of this article ?

  9. Bob says:

    I see the full article so I don’t know what you believe is missing. What particularly are you looking for that you didn’t see?

Leave a Reply

Your email address will not be published. Required fields are marked *