TFS Integration Tools – Which Rational ClearCase adapter should I select? Q&A-46

  • Article

When configuring a Rational ClearCase migration session you are currently confronted with the choice of three adapters. So which one should you select?

First, let us discuss some of the migration strategies (Recap)

It is important to consider migration over synchronization where you can.

A big-bang migration is not always feasible, but is generally best for small teams with manageable process-related tooling needs. The short-term impact can be considerable, however, the ongoing maintenance cost is close to zero. When reviewing the migration strategies the recommendation is to consider them in the listed order, because complete history is often not required and seldom missed.

If migrations cannot be performed within a manageable down-time maintenance window or if a business requirement necessitates the source and target environments to co-exist, we can consider synchronization. It is important, however. to consider migration over synchronization where you can.

  … moving (migrating) one sofa is easier than having to consolidate (synchronise) two sofas

When reviewing the migration strategies the recommendation is to consider them in the following, because complete history is often not required and seldom missed:

  • Simple … synchronise a single integration path
  • Multiple … synchronise a set of independent branches
  • Full … synchronise all branches and history

Now we can revert back to the original thread … which adapter is the right one?

  • The ClearCase Detailed History Adapter is used when we want to move complete or multiple history. The latter can be done by defining a set of migration paths.
  • The ClearCase Selected History Adapter moves one version at a time and selecting which history to move.

To use the selected history adapter, you could implement the following example strategy:

  1. Create a CC config spec that selects a version from the version control tree (t0)
  2. Create an aggregate comment, for example by combining detailed comments, version and date/time information. Write this information to a semaphore file in a predefined drop zone, which could trigger a migration.
  3. TFS Integration Platform selected history adapter migrates the selected tree into TFS.
  4. Update the config spec to select a tree from t0 + elapsed time.
  5. Re-do step 2.
  6. TFS Integration Platform selected history adapter computes the difference and migrates the delta into TFS.
  7. … go to step 4

This is the approach being used by some of our largest customers since it frees them to choose the granularity and depth of history moved to TFS rather than forcing them to try to play back CC history in fine detail. Developers will still see a progression of changes over time in TFS and they retain the ability to compare files to historical revisions.  They leave fine-grained audit history in CC but in doing that make the process of migrating content to TFS something that is much simpler and much more easily managed.

… Thanks to Bill Essary for the input, which I loaned from a support discussion thread :)