Why are we getting a "Delivery Failed...as it would create conflicts in the stream" error when delivering a subset of the change sets in a workspace?
Craig Hibbert (30●7)
| asked Sep 04 '15, 9:40 a.m.
converted to question Sep 04 '15, 3:43 p.m. by Geoffrey Clemm (30.1k●3●30●35)
We had a large number of change sets ready to deliver with all conflicts resolved and no outstanding incoming changes. Like William, we too had a single "DO NOT DELIVER" change set containing various fluff that we wanted out of the 'Unresolved' tree but had no intention of delivering (utilizing .jazzignore in this case is inappropriate for us for unrelated reasons).
Attempting to deliver the change sets (except the aforementioned "DO NOT DELIVER" change set) resulted in the same exception seen by William.
The error threads spoke of conflicts but we were unable to work out how to resolve the problem.
After a full morning of trying various approaches, all of which resulted in the same outcome, we binned the "DO NOT DELIVER" change set and tried to deliver all the others. This time it worked and a conflict with one of the files was exposed in the expected way, ready for us to merge.
I believe there is an issue here with how RTC reports exceptions to the user. The messages we received were, at best, misleading and, at worst, wrong.
|
Accepted answer
|
Just to be clear, we solved the problem described here by eliminating the "DO NOT DELIVER" change set and retrying delivery of all the changes.
As Ralph suggests in his answer, we could have tried suspending the change set instead, which would probably have resulted in the same outcome.
Ralph Schoon selected this answer as the correct answer
|
One other answer
Ralph Schoon (63.1k●3●36●46)
| answered Sep 04 '15, 10:09 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Sep 07 '15, 10:34 a.m.
Just not delivering a change set does not remove the changes from the files. You should have suspended the "DO NOT DELIVER" change set. I am not sue how that could cause the conflicts, but this is pretty hard to do from a forum anyway.
Comments Thanks for the pointer Ralph. I guess, rather than bin the change set, we could have suspended it, proceeded with our delivery and then resumed it afterwards.
I'll keep that in mind for another time.
|
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.
Comments
I believe this issue is a duplicate of the problem described in this question. The above was originally posted as a potential answer to that question (because it describes how we ultimately solved the problem), which is why you find references to "William", who was the question author.
When you add a comment to a previously answered question, very few people see it (except for someone hyper-diligent, like Ralph :-). I thought your post deserved wider attention, because although you found a workaround, I completely agree with your comment that this behavior is unintuitive (messages either misleading or wrong). The answers to the original question (including mine :-) were pretty generic, and I didn't think they got to the heart of the issue you were encountering. So my intent was to give your issue wider exposure, so we could get additional comments on what you were seeing. So apologies if this was confusing ... my intent was to compliment you on raising a significant issue, not confuse you! In the future, I'll try to remember to leave a placeholder reference in the original question, to make it easier to find.