shifting labels in RTC
Can I do the following in RTC?
In our CC solution we have a script that is being called from the GUI of the product the client is working in. This checks in a new version of a file which the product stores temparily in a directory. So the client never even sees the CC gui / has to be in CC. I think this may be done with scm.exe While doing this a popup is shown to the client to select one of his open activities (via TK), the version is then stored against that specific activity in that specific stream (I hope we can achieve this with scm). Now... what also happens is that this new version will evoke a labelshift on the new version OR if it is a new element a label will be set on the first version. Based on other changes coming in we run reports on these labels to e.g. determine what needs to be merged between releases. Is this last part possible in RTC via scm.exe / other ideas how to let this work? |
2 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 01 '10, 6:59 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
A ClearCase "floating label" is implemented in RTC-SCM as a "stream".
So for continuity for your users, you can create a stream named the same as the old floating label. Then to "float the label" to the versions you just checked in, "deliver" the RTC-SCM change sets to that stream. Cheers, Geoff On 11/1/2010 3:08 AM, edelwater wrote: Can I do the following in RTC? |
A ClearCase "floating label" is implemented in RTC-SCM as a "stream". Yes but I need shifting labels on individual elements, per stream. We use it for parallel development. In release 1 users work on an element and create new versions. In release 2 users work on that element and create new versions. the label indicates which elements can be copied from release 1 to release and which elements need to be merged from release 1 to release 2. So it is used by the merge and sync manager (since we may not merge these elements inside RTC) (they are Siebel objects). so if an element is changed a new version (version 7) is created without the label, and maybe even a version 8. The label was on version 6. If that element was not changed in the next release (know this by label in next release) the merge and sync manager can simply copy it over. If that elemant also has new versions since the last label the merge and sync manager knows he first has to (manually in siebel) merge version 7 (with the description of that activity) and then merge version 8 manually in siebel (with the description of that activity). This is just one of the use cases: when a new parallel release starts (running multiple next to each other) all elements get a label on their latest versions. So on day 1 changes from the previous release can just be copied (we know which ones to copy because of the labels). As soon as 1 element gets a new version that element may no longer be copied but must be merged manually in Siebel. The labels provide the basics for reports presented to the merge and sync manager. I'm trying to implement that use case in RTC. But I have difficulty to understand IF that use case is implementable in RTC. |
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.