In the matrix below you'll find the instances where LemonTree currently detects a conflict, and which version LemonTree will prefer.
|Change Type||Unmodified in A||New in A||Modified in A||Moved in A||Removed in A|
|Unmodified in B||No Conflict||Not Possible||No Conflict||No Conflict||No Conflict|
|New in B||Not Possible||No Conflict|
|(1)||Not Possible||Not Possible||Not Possible|
|Modified in B||No Conflict||Not Possible||Conflict:A (2)||No Conflict||Conflict:B|
|Moved in B||No Conflict||Not Possible||No Conflict||Conflict:A (3)||Conflict:B|
|Removed in B||No Conflict||Not Possible||Conflict:A||Conflict:A||No Conflict|
1) In case the new elements are identical in both models, LemonTree doesn't detect a conflict . (since Release 2.1.4). "New-New" scenarios with same GUIDs can happen if parts of the model are imported via .xmi.
2) Only a conflict if there is at least one property which is modified in both models.
3) In case the element is moved to the same location in A and B, LemonTree doesn't detect a conflict.
LemonTree respects such integral features. If you select an element to be part of the merge, for example because it was deleted in one branch and you don't want it to be deleted in the merged model, LemonTree also selects the integral features of this element, so that the element is complete. However, if an integral feature has been deleted in one branch, LemonTree respects this and will not resurrect this element, in contrast to existential dependencies where this feature would have to be resurrected in order to get a valid model.