Dependencies between Work Items with intersecting change-set
It looks like we are unable to deliver the change-set of Work Item B if its change-set intersects with Work Item A's (A was done before B on same stream). This is also the case in the world of ClearCase UCM, rightfully so.
However, I was hoping that RTC would give the user a supplementary level of flexibility where he could deliver only the contents of the second change-set, if he judges that it could be safely delivered independently of the first one. This is a long battle we'd had with UCM for which nothing could be done other than bypassing UCM and going with a base ClearCase merge operation. Can something be done in RTC to achieve this level of flexibility? |
4 answers
The simple answer is that we don't allow you to deliver any change-sets to a stream if they are to cause a conflict (eg, fork an item in the stream) to an item. But other than that, you can deliver what you want, in the order you want, without being forced to accept as well.
In your message, if what you mean by "safely deliver" is that it doesn't cause conflicts, then yes, this is supported. If you are really stuck and want to untangle some change-sets, for example they are based on one another and you wan't them to be, then you can suspend them, then resume the ones you want to deliver by-themselves, resolve any conflict this may cause, and deliver the change-set by itself without the other. |
|
OK. I will try out the scenario you are suggesting. But if it is too demanding on the part of the user I would like to write a Work Item for it, if you don't mind.
Jazz offers a wide range of new possibilites and I would really like to capitalize on them in order to avoid getting to a complete stand still like we are with UCM. ;-) |
|
It would be great if you could try this out in RTC and let us know how it goes. For us, it's not something that has happened much at all in development, so I'd like to hear not only the scenario but the development style/patterns which would cause this to happen.
|
|
OK. Understandably this is a pattern seldom seen during Development, which explains why you haven't encountered it. We see it happening frequently mostly during Maintenance and dealing with it forced us into some level of unwanted "creativity" with UCM that we'd love to get away from with Jazz.
Will send more material to this community shortly. |
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.