How to NOT deliver part of a change set
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?
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
On 2011/02/03 10:08, ScottChapman wrote:
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
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
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
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
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?
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?
On 2011/02/03 18:23, ScottChapman wrote:
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
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
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.
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.