Home » Modeling » Compare » EMF Compare merge conflicts problem
| EMF Compare merge conflicts problem [message #1753514] |
Tue, 07 February 2017 11:13  |
 Monica Coman
Messages: 13
Registered: January 2017 |
Junior Member |
|
|
Hi!
I am using EMF Compare to handle model merging in my own EMF-based application and I have encountered a problem in the UI when merging conflicts.
In the picture below you can see the conflicts I'm looking at:
What basically happened, in this case, is the following:
1. On the remote, a Component has been deleted;
2. Locally, a Variable has been added to the same Component which was deleted remotely. (in our ecore model, Variables are contained in a Component)
This, of course, resulted in a conflict.
What I don't understand is how are the relations between these 3 differences shown as conflicts created?
In the background, the difference selected in the picture above only has the ResourceAttachmentChange in the implies list but its acceptance also seems to influence the addition difference. Why is that and where could that relation come from?
Moreover, even though the UI shows that accepting the currently selected difference will accept the 2 others as well, what happens in the background is that both the Addition and the ResourceAttachmentChange are rejected.
Last but not least, even after accepting the selected difference, the UI shows the reject 'x' sign on all differences, see the picture below:
So it seems like the UI and input are somehow not in sync?
Thanks,
Monica
|
|
|
| Re: EMF Compare merge conflicts problem [message #1753621 is a reply to message #1753514] |
Wed, 08 February 2017 08:54  |
|
Hi Monica,
You have three differences
- Left: variables add
- Right: components delete, "uncontrol" of component
The conflict is between left variables add and right components delete
Quote:What I don't understand is how are the relations between these 3 differences shown as conflicts created?
In the background, the difference selected in the picture above only has the ResourceAttachmentChange in the implies list but its acceptance also seems to influence the addition difference. Why is that and where could that relation come from?
There is a relationship between right components delete and right "uncontrol" of component, because the deletion of the component entails the "uncontrol", if the component is a root element in its resource. I don't know by heart, but I guess, the resource attachment change should show up in the requiredBy list of the reference change. As a background info, the requirement-relationships are defined by the org.eclipse.emf.compare.req.DefaultReqEngine.
If you now accept the components delete, you'll automatically accept all its requirements and reject all its conflicting diffs on the opposite side (which is the addition of the variable in this case).
Quote:Moreover, even though the UI shows that accepting the currently selected difference will accept the 2 others as well, what happens in the background is that both the Addition and the ResourceAttachmentChange are rejected.
Yeah, I'm pretty sure there is a bug that the colors of the consequences are wrong. It'd be great if you could post your (or a simplified) model comparison scenario (the three models), to reproduce the wrong colors of the consequences. Conflicting diffs should show up with a red background color and not a green one.
Quote:Last but not least, even after accepting the selected difference, the UI shows the reject 'x' sign on all differences, see the picture below:
I'm afraid, this is a bug too. But at least it is known and there is already a patch on its way (see https://git.eclipse.org/r/#/c/90181/).
Hope that helps,
Philip
--
Philip Langer
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
--
Philip Langer
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
|
|
|
| Re: EMF Compare merge conflicts problem [message #1753741 is a reply to message #1753621] |
Thu, 09 February 2017 14:29 |
Monica Coman
Messages: 13
Registered: January 2017 |
Junior Member |
|
|
Hi, Philip!
Thanks a lot for your answer 
Quote:Yeah, I'm pretty sure there is a bug that the colors of the consequences are wrong. It'd be great if you could post your (or a simplified) model comparison scenario (the three models), to reproduce the wrong colors of the consequences. Conflicting diffs should show up with a red background color and not a green one.
Unfortunately, I cannot really provide the models to reproduce the issue since they wouldn't really work outside of our application. So, unless you can reproduce it with the info I provided above:
a. Left - add containment reference on an element;
b. Right - delete that element which gives 2 changes: delete containment reference on the element's parent (eContainer) and "uncontrol" of the element;
Then we'll have to wait until someone who can provide the models finds this issue as well 
Quote:I'm afraid, this is a bug too. But at least it is known and there is already a patch on its way (see https://git.eclipse.org/r/#/c/90181/)
This sounds like good news! Do you have any timeline for when a patch with the fix will be released? I couldn't really figure out the status of the issue from the link you sent.
Quote:There is a relationship between right components delete and right "uncontrol" of component, because the deletion of the component entails the "uncontrol", if the component is a root element in its resource. I don't know by heart, but I guess, the resource attachment change should show up in the requiredBy list of the reference change. As a background info, the requirement-relationships are defined by the org.eclipse.emf.compare.req.DefaultReqEngine.
It is true that the component is a root element in its resource. However, the resource attachment change does not appear in the requiredBy list of the reference change. It appears in none of its lists actually!
The only connection I could find between the resource attachment change and the reference change was the requires lists which contained the same 2 reference changes.
A small clarification, just to be sure we're on the same page:
- the components delete reference on the right is in one file (the file which contains the component's parent/eContainer) and the component itself is in another file hence the "uncontrol" change when deleting the component/the file.
An interesting observation is that if I consider the opposite case:
a. Left - delete that element which gives 2 changes: delete containment reference on the element's parent (eContainer) and "uncontrol" of the element;
b. Right - add containment reference on an element;
Everything works exactly as expected.
I tried to explain all the tests I made and the behavior I experienced in the table below.
-the numbers show the order of the actions performed by the user
-auto means a difference was accepted/rejected due to a user action
Attachment: table.png
(Size: 25.70KB, Downloaded 882 times)
|
|
|
| Re: EMF Compare merge conflicts problem [message #1753940 is a reply to message #1753741] |
Mon, 13 February 2017 08:33 |
|
Hi Monica,
Quote:Unfortunately, I cannot really provide the models to reproduce the issue since they wouldn't really work outside of our application. So, unless you can reproduce it with the info I provided above:
a. Left - add containment reference on an element;
b. Right - delete that element which gives 2 changes: delete containment reference on the element's parent (eContainer) and "uncontrol" of the element;
Then we'll have to wait until someone who can provide the models finds this issue as well
That's a pity. It'd be very helpful if you could create models to reproduce the problem (e.g. Ecore models).
Quote:This sounds like good news! Do you have any timeline for when a patch with the fix will be released? I couldn't really figure out the status of the issue from the link you sent.
I don't think there will be an intermediate release. So the next release will probably be together with Oxygen (June 2017).
Quote:The only connection I could find between the resource attachment change and the reference change was the requires lists which contained the same 2 reference changes.
Ok, requiring the same change does not mean that they will be always be merged together. I now re-read your first post, however, and there you write that the component delete _implies_ the resource attachment change, right? This causes the resource attachment change to be merged whenever the component delete is merged. I suggest to debug into this method:
org.eclipse.emf.compare.merge.AbstractMerger.getImpliedMerges(Diff, boolean)
There you'll see how the implied diffs are handled in the successful case and what is different in the failing case. It'd be great, if you could report your findings back and report a bug with example Ecore models, if necessary.
Thanks and best wishes,
Philip
--
Philip Langer
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
--
Philip Langer
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
|
|
| |
| Re: EMF Compare merge conflicts problem [message #1764984 is a reply to message #1764772] |
Mon, 05 June 2017 13:19 |
|
Hi Monica,
yes, the method has been introduced in 3.5. You can always start debugging in
org.eclipse.emf.compare.merge.AbstractMerger.copyLeftToRight(Diff, Monitor)
and
org.eclipse.emf.compare.merge.AbstractMerger.copyRightToLeft(Diff, Monitor)
to see which diffs get pulled in during the merge and why.
Since a new version of EMF Compare will be released end of June, it may pay off to work with the current master and switch to the released version then, as there has been many changes in the diff dependency management during the merge.
Best wishes,
Philip
--
Philip Langer
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
--
Philip Langer
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
|
|
| | | |
| Re: EMF Compare merge conflicts problem [message #1768376 is a reply to message #1768149] |
Tue, 18 July 2017 07:32 |
|
Hi,
3.3.1RC4 is the actual release of 3.3.1, but I've yet to properly rename the release bits. The problem Monica describes in that other message is something I cannot debug though, we would need test samples to reproduce and hopefully fix.
Regards,
Laurent Goubet
Obeo
|
|
|
Goto Forum:
Current Time: Fri Jan 03 04:39:23 GMT 2025
Powered by FUDForum. Page generated in 0.04684 seconds |
] 
Search
Help
Register
Login
Home
