|Possible issues with EMF compare? [message #727495]
||Wed, 21 September 2011 12:58
| Doug Tedd
Registered: September 2011
I am investigating the use of EMF Compare for a project where I need to be able to perform a 3-way match + diff + merge. I created a number of tests cases for the scenarios that need to be supported to see what sort of results EMF compare would give. Using EMF compare 1.2, a number of the cases give unexpected results and one even results in an ArrayIndexOutOfBounds exception. I see from recent blog posts that a lot of effort is being put into fixing issues for version 1.3. So, I switched to the latest 1.3.0 nightly build from 2011-09-12. With this version, the ArrayIndexOutOfBounds exception is solved but some of the other unexpected behaviors still exist. Here are the scenarios:|
For attributes, running a diff on each of the following situations results in a Conflicting UpdateAttribute. In these situations, I would not expect to see either a Conflict or a difference as the exact same changes are made to both the local and remote models:
- Add the same new attribute to the local and remote models and give them the exact same value.
- Update the same existing attribute on the local and remote models with the exact same value.
- Delete the same existing attribute from the local and remote models.
For ordered references that are either contained or uncontained, if the order of references is changed in the remote model and left untouched in the local model, the ReferenceOrderChange difference indicates that the change was local instead of remote i.e. calling isRemote() returns false.
For ordered references that are either contained or uncontained, if a change in is made in the order to the local and remote references I would expect to see a conflict. However, the ReferenceOrderChange difference does not indicate that a conflicting change was made i.e. calling isConflicting() returns false.
For an uncontained ordered reference, deleting a reference from the remote model and leaving the local model untouched results in 2 differences: ReferenceChangeLeftTarget and ReferenceOrderChange. The ReferenceChangeLeftTarget is expected due to the deletion of the reference but the reference order change was not expected.
A similar situation exists (unexpected ReferenceOrderChange) for deleting from the local only and when deleting a difference reference from the local and remote.
For an uncontained ordered reference, a reference is removed from a container in the local model. In the equivalent container in the remote model, the location of a reference is moved. Performing a merge on this (remote to local/right to left) results in the local and remote models being different from each other. The local model has regained its removed reference and the remote model has one of its references removed (the one that was originally removed from the local model).
Please could someone have a look at these scenarios? Maybe they are issues or maybe it is simply my misunderstanding of how the compare should work.
I have attached an eclipse project containing the test model and tests cases that I used. Also, I managed to find a workaround for scenarios 1 to 4 by patching 2 files. The patched version of these files are also attached:
[Updated on: Wed, 21 September 2011 15:26]
Report message to a moderator
Powered by FUDForum
. Page generated in 0.01826 seconds