We are attempting to import multiple labels and branches from base ClearCase into RTC. There have been a number of issues conducting the import. Some of them have been solved or there may be a work around, but it would be good to get some feedback on why these are occurring and whether we have been following a sound path for importing.

Some background:
We are attempting to import the following list of labels from the branches listed on the left.

int_1x_br : CC_MIGRATION_012609, 1.10.2.8, 1.10.3.2, 1.10.3.4
int_2x_br : 2.3.0.17, 2.4.0.10, 2.4.0.11
int_3x_br : 3.0.0.32, 3.1.0.4

Unfortunately, our first attempt to import from the int_1x_br branch failed due to an unexpected restart of RTC. However, we were able to restart the import and complete the import of the CC_MIGRATION_012609 label. The stream and component were created and we were eventually able to import the remaining labels associated with the int_1x_br branch. We then continued with importing labels associated with the int_2x_br branch. Note that all labels are fully applied to the directory structure and the label types have been locked. An attribute, RTC_IMP_STR_1, was applied to the label types with increasing values as follows.

CC_MIGRATION_012609: 1
1.10.2.8: 2
1.10.3.2: 3
1.10.3.4: 4
2.3.0.17: 5
2.4.0.10: 6
2.4.0.11: 7

Here are the issues we encountered:

1. We attempted to use an integer type for the RTC_IMP_STR_1 attribute and for some reason the importer ignored labels 1.10.2.8 and up, but imported CC_MIGRATION_012609. Once the attribute type was changed to be a string type, the import began to recognize the labels.
2. We attempted to limit our import of the import of 1.10.2.8 and up to a subset of the directory structure, but for some reason all directories were imported from the original root. This may simply be a misunderstanding of how roots are treated, but did cause confusion.
3. We then attempted to import all of the labels on the int_2x_br branch into a new synchronized stream. Again, we restricted it to a subset of the directory structure. This time the restriction worked. However, the 2.3.0.17 label appears to have been ignored and no baseline is associated with it. Below is a list of the baselines for the SFS_ADE_DGA component.

8: lbtype:2.4.0.11@\SFS_ADE_DGA, 12:13:37 PM (5 hours ago)
7: lbtype:2.4.0.10@\SFS_ADE_DGA, 2:10:06 PM (5 hours ago)
6: Backup before replace, Apr 17, 2012 10:11 AM
5: lbtype:1.10.3.4@\SFS_ADE_DGA, Apr 16, 2012 5:44 PM
4: lbtype:1.10.3.2@\SFS_ADE_DGA, Apr 16, 2012 5:36 PM
3: lbtype:1.10.2.8@\SFS_ADE_DGA, Apr 16, 2012 4:24 PM
2: Backup before drop, Apr 13, 2012 2:48 PM
1: Initial Baseline, Apr 12, 2012 9:46 AM

The Backup before baselines appear to have been created during our attempts to recover from the first import failure and then subsequent attempts to discover why we were not seeing what was expected. Although, it would be good to understand the exact meaning of these types of baselines.

The following shows the two streams and components created by the imports. Note, that we used a separate import to create the second stream called 2.3.0.17.

Source Control -> Components: SFS_ADE_DGA (Project Scoped)
Stream : 2.3.0.17 (CC_RTC_Import): Component: SFS_ADE_DGA (8: lbtype:2.4.0.11@\SFA_ADE_DGA)
Stream: CC_MIGRATION_012609 (CC_RTC_Import) Component: SFS_ADE_DGA (1: Initial Baseline)

When viewing the baselines for the component under the 2.0.3.17 stream we see the following.

8: lbtype:2.4.0.11@\SFS_ADE_DGA, 12:13:37 PM (5 hours ago)
1: Initial Baseline, Apr 12, 2012 9:46 AM

When viewing the baselines for the component under the CC_MIGRATION_012609 stream we see the following.

1: Initial Baseline, Apr 12, 2012 9:46 AM
5: lbtype:1.10.3.4@\SFS_ADE_DGA, Apr 16, 2012 5:44 PM
6: Backup before replace, Apr 17, 2012 10:11 AM
1: Initial Baseline, Apr 12, 2012 9:46 AM

It appears to be a bug in the display or we have done something that has caused an underlying problem.

Possible work around:
Start over and import all labels into a single stream and then create separate release streams based on specific labels.