Just for your awareness, a new migration tool is available with RTC 4.0.5 and higher. It can import all the versions from Rational ClearCase, so you can find similar version tree for files in RTC's history view:

https://jazz.net/wiki/bin/view/Deployment/RationalTeamConcertAndRationalClearCaseIntegrationCookbook#Rational_ClearCase_Version_Impor
https://jazz.net/downloads/rational-team-concert/releases/4.0.6?p=news#clearcase-importer
https://jazz.net/downloads/rational-team-concert/releases/4.0.5?p=news#CC-405-M2

Hi,

When you talk about source code migration, I assume you are thinking ClearCase Synchronizer one-way import as described in the RTC - ClearCase cookbook?
There are articles on developerWorks describing experiences for ClearCase migration in internal IBM projects. The jazz article on the ClearCase importer also has hard migration data.
That said, the physical import is only part of migration. In my experience it is vitally important to be clear on the reasons for migration and the expected SCM use cases. Among the things to consider:
- only ClearCase has dynamic views and file-based version trees / meta data
- only RTC has true change-set based components
- only ClearCase has MultiSite capability ...
- ... but 95% of distributed SCM use cases are very gracefully handled by RTC

The results of these considerations might be that aside from physical source code import you need to calculate time / effort for analyzing and adapting home-grown scripts and triggers. Sometimes, the finding may be that a lot of scripts are no longer necessary due to what RTC offers out of the box.

In one of my projects, it was found that we actually do not need the ClearCase history to be imported. The migration step was used as an opportunity to revamp the underlying architecture by relinking source folders via symlink into a new component structure in ClearCase. Once the sources built correctly in the new structure, we used flat-file import into RTC components. The home-grown build scripts could largely be replaced by build definitions in RTC: much less maintenance for scripting infrastructure.

The source code import from ClearCase is very capable of also importing history. Since importing all history is usually neither desirable nor necessary, you need to mark the label types you want to import by an attribute you create. The attribute will number the label types (e.g. baselines) and they will be imported in the resulting order.

The biggest effort after the migration is to make users understand
- why there is no version tree in RTC like in ClearCase
- why there is no NEED for a version tree in RTC like in ClearCase

The new Locate Change Set editor helps with the transition to the new change set paradigm.

Is this answer helpful? What other aspects of migration experiences would you like to see shared?

- Arne