How is this possible:
Solved
Merge Session says conflict exists, while all conflicts have been solved
+21- Superhero
Best answer by Mark Jongeling
Hi Harm,
That is due to unresolved conflicting delta actions. Either the Origin or the Branch delta action has to be applied. Currently, there is at least one set of delta actions that do not meet the requirements. Manually changing has_dynamic_conflicts will cause the merge to fail most likely, although an Update delta action may actually not cause an error.
Using the following, you can see which conflicts are the problem:
select *
from merge_conflict mc
join merge_conflict_type mct
on mct.merge_conflict_type_id = mc.merge_conflict_type_id
join delta_action dat
on dat.merge_session_id = mc.merge_session_id
and dat.delta_type = mc.origin_delta_type
and dat.delta_action_id = mc.origin_delta_action_id
and dat.available = 1
and dat.apply > 1
join delta_action dab
on dab.merge_session_id = mc.merge_session_id
and dab.delta_type = mc.branch_delta_type
and dab.delta_action_id = mc.branch_delta_action_id
and dab.available = 1
and dab.apply > 1
where mc.merge_session_id = <MERGE SESSION ID>
This topic has been closed for comments
+23Hi Harm,
When starting a merge session, the Software Factory will compare all changes between the two branches and determine any conflicts. After that all done, it will try to automatically resolve any conflicts so that it would have less impact when executing the merge session.
One example is for instance, when adding a column in the branch and adding the same column in the origin with the exact same configuration. This is a so-called "double insert" conflict. The Software Factory will then automatically resolve the conflict for you, and will resolve it by choosing the action that has the least impact on the execution. If you were merging the branch into the origin, the Software Factory will resolve the conflict by choosing the Origin action - so the action of the branch will be ignored.
There are a couple of more scenarios where the Software Factory will automatically resolve conflicts. In the Conflicts tab, you can disable the prefilters to see the conflicts that are resolved. The "Merge conflicts" column is correct in showing there are (or were) conflicts. Once all are resolved, either automatically or manually, the execution of the Merge session can begin.
Hope this clears it up!
+21- Superhero
Mark,
Thanks for you response.
Sorry, it is still not clear to me. I created a merge session and 6 (control procedure) conflicts were detected. I like to keep the branch version, so i resolved these manually by choosing the option “Only carry out the branch action”.
After this I expected to be able to start the merge process, but it does not.
Any more suggestions
+23Hi Harm,
Do you get an error message upon executing the merge session? If so, could you share the message?
Changing automatically resolved conflicts should be possible to a certain extend. When the Software Factory resolves conflicts, the conflicts usually are the same on both sides, as in the same object was added, edited with the same properties or deleted. Choosing the branch action rather than the origin action the SF chose, should not change the result.
I'm not entirely sure what is not working well in your situation. We could help you with this better through a TCP ticket. It may well even be a bug.
+21- Superhero
Mark,
This is the error I get:
Please help, I am in a hurry now, need to do a sync during lunch time, the original idea was to do it last night.
I will create a ticket in TCP. Hope it can be solved ASAP. :-(
Else, I think about setting the field “has_dynamic_conflicts” to False in the “merge_session” table manually, if possible, and see what happens, it cannot wait.
+23Hi Harm,
That is due to unresolved conflicting delta actions. Either the Origin or the Branch delta action has to be applied. Currently, there is at least one set of delta actions that do not meet the requirements. Manually changing has_dynamic_conflicts will cause the merge to fail most likely, although an Update delta action may actually not cause an error.
Using the following, you can see which conflicts are the problem:
select *
from merge_conflict mc
join merge_conflict_type mct
on mct.merge_conflict_type_id = mc.merge_conflict_type_id
join delta_action dat
on dat.merge_session_id = mc.merge_session_id
and dat.delta_type = mc.origin_delta_type
and dat.delta_action_id = mc.origin_delta_action_id
and dat.available = 1
and dat.apply > 1
join delta_action dab
on dab.merge_session_id = mc.merge_session_id
and dab.delta_type = mc.branch_delta_type
and dab.delta_action_id = mc.branch_delta_action_id
and dab.available = 1
and dab.apply > 1
where mc.merge_session_id = <MERGE SESSION ID>
+21- Superhero
Before manually resolving the conflicts, this is the result:
And after:
As you can expect, so I see no reason why the value of “has_dynamic_conflicts” is still True
+23That is indeed strange as the Update Trigger should toggle this column's value. In that case, feel free to change the value manually of has_dynamic_conflicts.
+21- Superhero
Thanks Mark,
After doing this I was able to run the merge process.
Very strange!
I will keep an eye on this, and inform you when it happens again.
You will understand that these kind of scenarios do not make me feel good about the platform.
+23Understandle Harm. We use the Software Factory ourselves thoroughly because we create the Software Factory model using itself. For every feature, bug or other reason we create branches and merge them after, and we have not encountered this a single time. We also haven't heard similar issues with this, so I think this may be an edge case that is very unlikely to happen again.
But of course, if there's a reproduction, we can take a good look at it and resolve it. Glad you are able to continue now and that the merge succeeded.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.