How to solve invisible conflicts
Hi,
We are working with RTC 5.0.2 A developer has many change sets in his repository workspace. Then he changes the flow target. He gets conflicts he succeds to solve. See image 1 to see the repository workspace of the user connected to another stream and with all outgoing change sets either merged or not. Trying to deliver the developer gets an error message he can overrule. See image 2 for illustration. But he then gets another error message saying there are conflicts but they ere not visible. See image 3 for illustration. Thank for your help. Regards |
2 answers
Ralph Schoon (63.6k●3●36●46)
| answered Oct 17 '16, 9:46 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Oct 17 '16, 9:51 a.m.
I have found, over the years, that it is a good idea to read error messages and try to understand what they are telling you. That saves a lot of time actually.
If you do that above, you realize that this is not really SCM and merge related and there are also no invisible errors. None of the errors mentions any conflicts or the like. There are compiler errors in your work-space and you have configure operational behavior that prevents you from delivering if you have compiler errors in your work space. The errors could be due to a merge or totally unrelated. Check the operation behavior in the project and team areas and remove that or fix the compiler errors in the work-space. Please also read this: Comments Ralph, thanks for the tip.
Than you Ralph !
I would fix the compiler errors first. In the process accept changes to your work-space. Otherwise the message does not ring a bell really. You could refresh and see if there are new incoming changes. I would assume to be able to see the conflict if there is one.
Ralph Schoon
commented Oct 17 '16, 10:03 a.m.
| edited Oct 17 '16, 10:04 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Expand the merge nodes and try to understand what the merges do. If this is due to a merge gap, at least I would assume some hints that this is the case.
Ralph Schoon
commented Oct 17 '16, 10:27 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Another thought: try to deliver a few change sets at a time to identify the problematic one. If you have a gap scenario that is not gracefully supported in 5.0.2 find the breaking change and then look into the component history if the change that does not deliver is based on another one that you are missing.
|
The likely cause of this is a difference in change set ordering between the stream and the workspace. This can happen in cases where Resolve with Proposed or Resolve with Mine was used to resolve conflicts. A workaround would be to:
1) Create a baseline on the OLIFSA-J2E component in the stream 2) Accept the baseline into the workspace This will force the change set ordering in the workspace to match the change set ordering in the stream. This will also likely result in conflicts in the workspace (given that the deliver failed). You can then resolve the conflicts and deliver. It is possible that the accept will fail due to an N-way conflict. In that case, you could do the following: 1) Suspend all outgoing change sets 2) accept the baseline 3) resume the change sets from 1) in smaller groups (1 or 2 at a time) and resolve the conflicts as you go. More information is available on this in article https://jazz.net/library/article/1498. Also, we have made some improvements to this situation in 6.0.2. |
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
There are no screenshots. If you don't have permissions to post images here due to low reputation, post them somewhere else and put a link in. With the information given there is no way to help.
Here are the images provided by Claude.
Ralph you're too fast ! The pictures are below