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?
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.
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. ;-)
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. ;-)
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.
Will send more material to this community shortly.