(This is the last in a three-part series of articles describing the migration of RTC SCM data to ClearCase.)
SCM Artifact Migration – Implementation Challenges
The previous blog in this series described the importing of RTC SCM metadata and content into ClearCase. What it didn't describe were the many challenges in accurately mapping SCM artifacts from the RTC data model to the ClearCase data model. For brevity, the most significant deficiencies that had to be accommodated for in RTC were:
Parents don't know their children
In ClearCase, the relationship between versioned file system objects are modeled as they are in the native OS – directories catalog their children. In addition, ClearCase directories are versioned so that you can easily see and query the changes to its catalog over time.
In RTC, unfortunately, that relationship is flipped and only partially implemented. In an RTC change, children have a pointer to their folder, and the folder knows nothing about the children. Worse, the only state for a folder is its name which the children never know - the pointer the children have to their parents identifies the base "element" and not the state which describes the name. Thus, there is no way in the context of a change to accurately get the name of a child's parent and build a path to the change.
To compensate, RTC captures these relationships in a "Configuration". In RTC a Configuration exists only in a baseline or workspace context – not at the changeset scope which is needed to accurately record name changes relative to that change history. By way of example, consider a baseline containing 100 changesets. In changesets 1-98, the path was for a change "/folder1/child" at the time the changesets were recorded. At changeset 99, the name was changed to "/folder2/stepchild". The path record at changeset 99 is now the only reported path available to changesets 1-98, which is not helpful for tracking the change history of the file in any context finer than the baseline. To compensate, the importer requires that it sees all changes for a stream/component since "the beginning of time", and builds those pathnames as it sees changes over time.
Lack of temporal order in changeset contents
Another challenge in correctly replaying the intent of a changeset into a ClearCase activity is the lack of reliable date/time information for a change in RTC. For example, often all the changes within a changeset can have the same date/time, with the change noting the addition of a folder listed after the changes recording the add of its children. This becomes further complicated in the context of a delete, rename or reparent change. To accurately record the original author's intent, the importer employs a heuristic of applying multiple passes to the changeset contents and ordering them such that they can be replayed in the correct order in ClearCase.
Figure 1 shows the ClearCase version tree for an element that has been renamed as well as merged.
I hope that you found these series of articles interesting and helpful in understanding the benefits ClearCase/UCM. If you would like more information on migrating your RTC artifacts to ClearCase and ClearQuest, feel free to contact the ClearCase/ClearQuest Product Manager at HCL, Howie Bernstein (firstname.lastname@example.org).
Todd Lainhart is a senior technical contributor to the ClearCase product family. Todd has developed software for over 30 years, focused mainly on the CASE and configuration management product spaces.