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? |
7 answers
On 2011/02/03 10:08, ScottChapman wrote:
While we are working on the current version of our product, we still 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 |
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? |
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.
|
On 2011/02/03 18:23, ScottChapman wrote:
A concrete example is that we often keep version information in a 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 |
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. |
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, |
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.