It's all about the answers!

Ask a question

How to NOT deliver part of a change set


Scott Chapman (3216547) | asked Feb 03 '11, 12:56 p.m.
While we are working on the current version of our product, we still have to maintain older releases. We do this by having a stream for current development, and another stream for maintenance which flows to the current dev stream.

On occassion we need to make a change in the maintenance stream but don't want all the files to get posted to the current dev stream.

In ClearCase we could work around this by creating a merge arrow for that version.

In absence of a functional equivalent in RTC (which I assume there is not) how does one avoid delivering a file in a change set? Is the only way to do it to deliver the unwanted file, but then create a new changeset in the current dev stream which effectively undoes the change?

7 answers



permanent link
David Olsen (5237) | answered Feb 03 '11, 5:38 p.m.
JAZZ DEVELOPER
On 2011/02/03 10:08, ScottChapman wrote:
While we are working on the current version of our product, we still
have to maintain older releases. We do this by having a stream for
current development, and another stream for maintenance which flows
to the current dev stream.

On occassion we need to make a change in the maintenance stream but
don't want all the files to get posted to the current dev stream.

In ClearCase we could work around this by creating a merge arrow for
that version.

In absence of a functional equivalent in RTC (which I assume there is
not) how does one avoid delivering a file in a change set? Is the
only way to do it to deliver the unwanted file, but then create a new
changeset in the current dev stream which effectively undoes the
change?

A change set cannot be broken up. It has to be delivered/accepted as a
unit. So you cannot avoid delivering just a few files within a change
set. This behavior is fundamental to RTC SCM.

So I see three choices:

1. The approach you suggested. Deliver the entire change set along with
an additional change set that undoes the things you didn't want to be
delivered.

2. Create a new change set that contains just the changes that you want.
Deliver only that change set to the dev stream. Creating a patch from
the original change set might help you create the new change set.

3. When making the original change in the maintenance stream, create two
change sets. One should be delivered to the dev stream, the other one
shouldn't. This would be my preferred solution, but it requires
thinking ahead, which isn't always easy to do.

--
David Olsen
IBM Rational

permanent link
Takehiko Amano (1.3k3741) | answered Feb 03 '11, 9:09 p.m.
JAZZ DEVELOPER
Why don't you use "suspend" ? This enables to go back to original state of workspace, as if there is no change made to the workspace.

Then, you can work on fixes and deliver to appropriate stream. After you finish working on fixes, then use "resume". Resume enables to recover changes made in "suspended" change set. Please see the article in jazz.net

http://jazz.net/library/article/41
"Suspending an Outgoing Change Set". This is very cool feature of RTC SCM!


Hope this helps !
Yamato Software Laboratory.
Takehiko Amano

permanent link
Scott Chapman (3216547) | answered Feb 03 '11, 9:21 p.m.
So, the problem is that the change I am delivering is important to the the stream that it flows to. But I do not want to have it flow beyond that.

A concrete example is that we often keep version information in a file. So, when we need fix a defect in an old release we want the fix associated with that defect to be delivered and propagate, but we want the new version information to also be delivered, but NOT propagate.

Make any sense?

permanent link
Takehiko Amano (1.3k3741) | answered Feb 03 '11, 10:38 p.m.
JAZZ DEVELOPER
I understood by the example. Unfortunately, as David have replied, change set can not be changed after the delivery to specific stream. Probably, creating another change set in advance is good idea for now.

permanent link
David Olsen (5237) | answered Feb 04 '11, 12:23 a.m.
JAZZ DEVELOPER
On 2011/02/03 18:23, ScottChapman wrote:
A concrete example is that we often keep version information in a
file. So, when we need fix a defect in an old release we want the fix
associated with that defect to be delivered and propagate, but we want
the new version information to also be delivered, but NOT propagate.

Make any sense?

Makes perfect sense. Not wanting to propagate the version information
was exactly what I thought of when reading your original post.

Put the fix in one change set. Put the version information in a
different change set. Since you want those to be delivered to different
places in the long run, they should be in different change sets from the
beginning.

--
David Olsen
IBM Rational

permanent link
Michael Valenta (3.7k3) | answered Feb 04 '11, 10:03 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
Scott,

If I understand you correctly, your issue is the one outlined in https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/107641. If this is the case, you may want to subscribe yourself to that work item and also make any comments if you have any.

permanent link
Scott Chapman (3216547) | answered Feb 04 '11, 6:27 p.m.
Yep, I think they get pretty close to what I am talking about at the end there, so I added a comment.

Basically I am looking for a way to say, "No thanks" or "Don't Accept" or "Reject" a change set to a stream.

Scott,

If I understand you correctly, your issue is the one outlined in https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/107641. If this is the case, you may want to subscribe yourself to that work item and also make any comments if you have any.

Your answer


Register or to post 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.