Community
Participate
Working Groups
Created attachment 257200 [details] Repo that illustrates the problem To reproduce, merge multiplicity1 into multiplicity2. The merge is performed without raising a conflict. However, on both sides, the multiplicity is changed in different ways on the same pin. Thus, a conflict would be expected instead. The underlying problem is that a UML Multiplicity Element (e.g., a property or a pin) initially doesn't contain a lowerValue and upperValue, which are both 0..1 containment references in the UML metamodel. If the user sets the multiplicity of a multiplicity element, the respective value objects (e.g., instances of LiteralInteger) are added to the lowerValue and upperValue references accordingly. However, at least in this case, EMF Compare does not raise a conflict when concurrently setting the 0..1 containment references, which leads to overwriting the multiplicity values when merging; thus, the multiplicity changes of one side get lost. It needs to be checked whether this issue also appears for general EMF models. In o.e.e.compare.tests.conflict.ConflictDetectionTest, it seems there are only tests regarding the conflict detection of 0..1 non-containment references (cf. testB3UseCaseForReference()).
New Gerrit change created: https://git.eclipse.org/r/58525
New Gerrit change created: https://git.eclipse.org/r/58524
Concurrent additions to single-valued containment references weren't reported as conflicts so far. Thus, I pushed a change to enable reporting such conflicts for general EMF models: https://git.eclipse.org/r/#/c/58524/ However, this bug is not fully fixed yet: for UML models, users would expect that setting the multiplicity to the _same_ values wouldn't be real a conflict -- only a pseudo conflict. In the generic conflict detection, we check after change 58524 whether the equality helper considers the added objects as equal; if it considers them as equal, only a pseudo conflict is raised instead of a real one. However, the equality helper will not consider two added EObjects as equal (because it uses the match model for that). Consequently, it also won't consider two UML instance specifications, which are used to express multiplicities in UML, as equal even though they specify the same value. So I'll put a UML-specific handling for this on top of the pushed change. I thought about solving this by customizing the equality helper for this purpose. We could let it return true if you ask for equality of two instance specifications that are contained by lowerValue and upperValue. The high road would be to introduce a UML multiplicity change and handle that in the UML-specific postprocessors. Do you have thoughts on that? Thanks!
Hi Philip, Nice catch ! I agree with your proposal, it seems to be a good solution for that problem. I will merge the first part https://git.eclipse.org/r/58524 of the contribution very soon. Thank you.
Gerrit change https://git.eclipse.org/r/58524 was merged to [master]. Commit: http://git.eclipse.org/c/emfcompare/org.eclipse.emf.compare.git/commit/?id=ab2602c796b9b5e7f90efe31140399304b22dd91
New Gerrit change created: https://git.eclipse.org/r/64974
New Gerrit change created: https://git.eclipse.org/r/66075
Gerrit change https://git.eclipse.org/r/66075 was merged to [master]. Commit: http://git.eclipse.org/c/emfcompare/org.eclipse.emf.compare.git/commit/?id=49497ead3dc1e340aa42ff72aae9001ae07e2d5e
Gerrit change https://git.eclipse.org/r/64974 was merged to [master]. Commit: http://git.eclipse.org/c/emfcompare/org.eclipse.emf.compare.git/commit/?id=6dfd995b7164e7a69aee10eaaf9858c5fb7c485e
