White Paper: Migration from IBM Rational ClearCase UCM to Subversion

Abstract

The purpose of this document is to consider the implications of performing a migration of data from IBM Rational ClearCase, specifically when using a UCM vob, to Open Source Subversion as a means of version control using the tool Migrate2SVN.

Prerequisites

Over the course of this document technical references will be made to the software in scope for discussion, the reader should have basic user knowledge of:

• IBM Rational ClearCase
• ClearCase UCM methodology and terminology
• Subversion (SVN)
• Clearvision’s Migrate2SVN tool

Introduction

The process of migrating base ClearCase data to subversion has been well documented, it should be noted that while the migration into GiT or Mercurial are possible from a ClearCase vob these migrations and their implications are not covered within the scope of this case study.

When using a base ClearCase vob activities are recreated in subversion as branches to and from the main branch, the entire history of a ClearCase vob can be copied in this manner. When migrating a UCM vob however other factors must be considered. Multiple streams must be copied and their history traced, as well as activities and rebasing/integration between streams. Once migration has completed however some of these tags may only appear in previous revisions of subversion, being replaced by new activities or labels over the course of the history.

In order to test these concepts a small UCM vob will be used. The vob will feature an integration stream as well as two development streams in a single project.

Figure 1.0 shows the ClearCase version tree of the vob in question.

Figure 1.0

This small vob contains labels, activities, integrations and a rebase. The vob also contains several unused components and a second unused project. These are in place as control objects to ensure the UCM objects migrate correctly.

Performing the Migration

The Migration was performed using an evaluation license of Migrate2SVN. The UCM vob suffered the same limitations as expected in a base ClearCase vob, such as unintended files on Main. However there were no errors during the migration showing the tool to be fully compatible with performing a migration on a UCM vob.

Results

The Migration completed, largely as expected. The repository contains both a branches and tags directory. Figure 2.0 and 2.1 shows the contents of the tags directory, and its ClearCase relationship.

Figure 2.0

figure 2.1

The latest revision (revision 59) shows that only the latest integration labels are represented as tags. Reverting the repository to an earlier revision reveals a different content in the tags folder revealing that Migrate2svn only shows the latest baselines as labels and removes them as they are replaced throughout the history. These tags directories are then populated by component directories and the contents of each at the relevant baseline.

Within the branches directory the repository is separated as each of the ClearCase streams. As shown in figure 3.0

Figure 3.0

Both of the project integration streams have been migrated as branches along with the Main and each of the development streams. These branches are then populated identically to that stream’s view within ClearCase, including components, sub directories and all files along with their contents.

Read Only ClearCase Components

It is a notable point that projects in ClearCase often contain components from other projects in a read only state. This feature, controlled in ClearCase does not migrate to Subversion. Permissions must be set separately in subversion to maintain control of the repository. By default all branches are accessible, and editable by anyone with access to the repository. It is worth considering however that the TEST_PROJECT, originally containing only one single component in an editable state, now contains four.

Conclusion

The results of this use case clearly show that the Migrate2SVN tool is entirely compatible with the Clearcase UCM layer. While Clearcase continues to provide known limitations to data available to a migration these are handled by the tool in the same way as a base vob and fully detailed in the tool’s documentation.