Migrating source management from ClearCase to RTC
Greetings,
My team is investigating the possibility of adopting RTC in our next release. My specific involvement so far is to look at available options for transitioning source management. We are currently using UCM ClearCase for the majority of our source, though we do use base ClearCase for other collections. I must confess that I am not terribly RTC conversant, and in truth, only barely CC literate. However, I appear to have had some minor success, and have also encountered a few "gotcha"s. Specific areas where I am looking for some guidance: 0) When importing from an existing UCM stream, do I need to be using something other than our main integration stream? The help guidance indicates the stream will be locked during import, which is ok. 1) Element history - I have used the selection to import all baselines; what this appears to accomplish is creating a change set in RTC for each baseline in my integration stream. The only history I can find in RTC is a notation of the baseline - I cannot find any of the activity information. Am I missing something or perhaps looking in the wrong place? 2) Element presentation - After successfully importing some source, the elements in RTC seem to have picked up some extra line terminations. Is there some way to control this or am I at the mercy of what the importer determines? 3) The online help identifies "ClearCase Synchronizer" and "ClearCase Importer" - are these really two different things or just different uses of the "ClearCase Connector"? |
5 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Jul 30 '10, 4:16 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
That is correct. In general, the place to get your ClearCase versioning
meta-data (such as version comments) and detailed ClearCase history will be from ClearCase, not from RTC. The underlying version models of ClearCase and RTC are different enough that "duplicating" the ClearCase meta-data and detailed history in RTC is not feasible. WRT history from Base CC, what is imported is a sequence of user-selected "configurations", where each configuration is the set of files/directories that are annotated by a user-selected label. But as with UCM CC, what is brought into RTC is the contents of the directories and files, not the versioning metadata (such as checkin comments) or detailed history (such as intermediate versions not selected by any of the user specified labels). We do pull over enough metadata so you can identify the corresponding object in ClearCase (e.g. the name of the baseline or the name of the label), but you would need to ask ClearCase for the historical metadata and historical versioning details. Cheers, Geoff On 7/29/2010 10:08 AM, DavidRoessler wrote: Sorry that it has taken a while to get back to this. If I read your |
Sorry that it has taken a while to get back to this. If I read your response correctly, the associated work item description is obtained from the recorded Activity ID of each UCM activity, contributing to deliveries captured in a baseline, rather then the change descriptions captured for each of the elements in a contributing activities' change set?
Unfortunately, that really doesn't help us much. We tend to favor verbosity in our revision history and rely on it to reconstruct past efforts. It would appear we won't be able to leverage the pre-RTC history captured for this. It has been suggested to us to make any move at a well-defined release boundary. At least in theory, a new release should not have as much "history" baggage to consider. We also have a number of Base ClearCase VOBs in use. Where does non-UCM import history come from? From what I've read, selection of versions is accomplished applying labels with a incrementing attribute. Both mklbtype and mklabel allow for a comment; which of course we have not used :)
Element history - I have used the selection to import all baselines; what this appears to accomplish is creating a change set in RTC for each baseline in my integration stream. The only history I can find in RTC is a notation of the baseline - I cannot find any of the activity information. Am I missing something or perhaps looking in the wrong place? |
Geoffrey Clemm (30.1k●3●30●35)
| answered Jul 01 '10, 8:43 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
One followup on question #2 on line termination: In RTC-3.0, the
sync-stream creation wizard will ask you for the line termination convention in use in your VOB, to avoid this coming as a surprise. Cheers, Geoff On 7/1/2010 1:09 AM, Geoffrey Clemm wrote: Comments interspersed below: |
Geoffrey Clemm (30.1k●3●30●35)
| answered Jul 01 '10, 1:09 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Comments interspersed below:
On 6/30/2010 6:22 PM, kesterto wrote: DavidRoesslerwrote: Yes, locking is the reason to not use your main integration stream. In particular, the initial import of a large vob can take hours, or even days (although subsequent synchronizations of that stream will be much faster). Are you sure it is OK to have your main integration stream locked for that long for the initial import? 1) Element history - I have used the selection to import all If you are using UCM, the UCM activity names should appear in the description of the work item associated with the import change set. But that is the extent to which activity information is imported. 2) Element presentation - After successfully importing some source, There is on-line help for this: "Specifying line termination characters for text files". Unfortunately, that help needs to be improved (I've submitted work item 119917). In particular, you need to tell the synchronizer what kind of line endings appear in your VOB. Based on what you are seeing, you have windows-style (CRLF) line delimiters in your VOB, so you need to change the synchronized stream LINE_DELIMITER property from its default (LF) to be CRLF. 3) The online help identifies "ClearCase Synchronizer" and Two modifications to the response above: - The synchronizer keeps a CC *stream* or *branch* (not *view*) in sync with an RTC stream. Although it does use a CC view to do so. - The importer is a one-way sync (from CC to RTC), but it is "multi-shot", i.e. you can request another "synchronize", and it will pick up any baselines/labels added since the previous import. Cheers, Geoff |
Greetings, I can help with 3) - they have different purposes. The Synchroniser is meant to keep a CC view and RTC Stream in synch - passing changes back and forth. The Importer is supposed to be a one-shot import of content from CC into RTC. regards anthony anthony |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.