It's all about the answers!

Ask a question

How to solve invisible conflicts


Claude MOUREY (9811) | asked Oct 17 '16, 8:51 a.m.
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

Comments
Ralph Schoon commented Oct 17 '16, 9:18 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.


Nicolas Dangeville commented Oct 17 '16, 9:38 a.m. | edited Oct 17 '16, 9:41 a.m.
JAZZ DEVELOPER

Here are the images provided by Claude.


Nicolas Dangeville commented Oct 17 '16, 9:38 a.m.
JAZZ DEVELOPER

Ralph you're too fast ! The pictures are below

2 answers



permanent link
Michael Valenta (3.7k3) | answered Oct 20 '16, 8:57 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
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.

permanent link
Ralph Schoon (63.1k33646) | 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
Nicolas Dangeville commented Oct 17 '16, 9:50 a.m.
JAZZ DEVELOPER

Ralph, thanks for the tip.
But actually this is the one in the process advisor that has been overruled, so it seems this is not the question asked by Claude..

Can you comment on "we need to restructure your change history" message ?


Claude MOUREY commented Oct 17 '16, 9:53 a.m.

Than you Ralph !
There is no possibility to change the process behavior as it has been set for all PA of the Company. But the command "Overrule" works well for such error message (workspace errors) as you can see in the screenshot. But in this case it is not sufficient.
Regards


Ralph Schoon commented Oct 17 '16, 9:59 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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. 

I know that we have spent a lot of work in developing a feature that helps with merge gaps. Maybe this is related. I don't know. My strategy is always to reduce potential issue areas. So solve the compiler issues first. Then try to figure why you would create a conflict on the stream. For all I see you shouldn't. Try to check the outgoing changes and check if you might have structural changes (folders, file structures).


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.

Your answer


Register or to post 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.