It's all about the answers!

Ask a question

Migrating source management from ClearCase to RTC


David Roessler (112) | asked Jun 30 '10, 3:02 p.m.
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



permanent link
Anthony Kesterton (7.5k5177136) | answered Jun 30 '10, 6:22 p.m.
JAZZ DEVELOPER
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"?


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

permanent link
Geoffrey Clemm (29.8k23035) | 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:

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.

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
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?

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,
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?

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
"ClearCase Importer" - are these really two different things
or just different uses of the "ClearCase Connector"?

I can help with 3) - they have different purposes. The Synchronizer
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.

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

permanent link
Geoffrey Clemm (29.8k23035) | 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:

On 6/30/2010 6:22 PM, kesterto wrote:
DavidRoesslerwrote:

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.

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
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?

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,
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?

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
"ClearCase Importer" - are these really two different things
or just different uses of the "ClearCase Connector"?

I can help with 3) - they have different purposes. The Synchronizer
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.

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

permanent link
David Roessler (112) | answered Jul 29 '10, 10:06 a.m.
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 :)



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.
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?

permanent link
Geoffrey Clemm (29.8k23035) | 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
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 :)


gmclemmwrote:

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.
DavidRoesslerwrote:
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?

Your answer


Register or to post your answer.