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