Eclipse Community Forums: Compare » [EMF Compare] Merge action not properly done

Home » Modeling » Compare » [EMF Compare] Merge action not properly done(The user interface's top panel shows the differences correctly, but when I try to merge the result is not what I expect)

[EMF Compare] Merge action not properly done [message #1745129]

Wed, 05 October 2016 09:52

Eclipse User

Hello,
I have models that comply to a custom meta-model, and I've coded some customization rules to manage the comparison (custom identifiers, feature filter, diff post processor, etc.). When I launch a comparison I can see the differences and the consequences of the merge (green highlights) correctly displayed on the top panel. I see only the differences I expect to see, the filter seems to work well etc.

But when I try to merge a diff from one model the other the diffs I expect to be "dependent" (which I see highlighted in green in the top panel) do not merge.

Let me use an image to explain it further.
index.php/fa/27302/0/

In my model, when a Port is added to a SubSystem, 2 items are actually added: the Port (here an Inport) and a PortBlock (here a InPortBlock). These elements have children (visible here because the "Cascading differences" filter is disabled). I wanted to display this set of (two) unit differences into a macroscopic change, so I applied a refinement. Here's the pseudo-code:

...
if (<is_port_diff(diff)>)
{
  Diff c_diff = <select_corresponding_portblock_diff(diff, all_diffs)>;
  if (c_diff != null)
    c_diff.eSet(ComparePackage.eINSTANCE.getDiff_RefinedBy(), new ArrayList<Diff>() {{add(diff);}});
}

The green highlights seem to indicate that if I merge the macro change (InPortBlock) all the dependent diffs will be merged. But this is what I get when I apply, e.g., a "Copy Current Change From Left To Right":
index.php/fa/27303/0/

As you can see the InPortBlock and the InPort (which refines the InPortBlock) are merged, but the children are not.

So, here's the question: how can I get merged all the model items I expect to be merged when I look the comparison result, and why are they highlighted in green but not merged?

Thanks in advance,
--
Matteo

Attachment: comparison.png
(Size: 139.01KB, Downloaded 713 times)
Attachment: merge.png
(Size: 8.38KB, Downloaded 669 times)

[Updated on: Wed, 05 October 2016 10:15] by Moderator

Re: [EMF Compare] Merge action not properly done [message #1745279 is a reply to message #1745129]

Fri, 07 October 2016 04:33

Eclipse User

Hello,

The display fo green and red highlighting to indicate the consequences of merging the selected diff is sensitive to the direction of the merge. So if you want to merge from left to right, you should toggle the button (right-to-left / left-to-right) to displays the consequences correctly.
Can you make sure the button is toggled properly (left-to-right) and tell us whether or not it is aligned with what actually happens when you merge from left to right?

Regards,

Laurent

Re: [EMF Compare] Merge action not properly done [message #1745471 is a reply to message #1745279]

Tue, 11 October 2016 06:15

Eclipse User

Hello Laurent,
in fact, the button was not toggled properly: if I select "Show from left to right" the green highlights is perfectly aligned with what actually happens when I do the merge. So now the question is:
should I use "implication" when I do the diffs refinements, to specify somehow that when I merge the InPortBlock what I want actually is to merge also all its children, plus the InPort plus all its children? Or maybe there is a better way to do it?

Thanks,
--
Matteo

Re: [EMF Compare] Merge action not properly done [message #1745534 is a reply to message #1745471]

Wed, 12 October 2016 04:13

Eclipse User

Hi,

You might want to look at the definition of the links we use between Diff in the developer guide to make your choice. I don't know exactly what your differences are and what kind of relation they hold with each other in your use case.... here's my understanding:

"In Port Block 51" in your first screenshot is the "high level" diff you have made being refined by "In Port 51". This refining relation only links these two differences.

If that assumption is correct, then the behavior you have is correct. when you tick "right to left" as the merging direction we put every diff in green because if you merge any of these differences we also need to merge their sub-diffs (since we're deleting the container of these elements in the model). However, if we're looking at the left to right direction, we do not "need" to merge the children when we merge the differences adding their parent in the model. That would be the job of the "cascading" filter. If you re-enable that filter the merge will do what you expect it to.

Relying on the cascading filter to do the job is probably not the best way to have your differences model properly reflect your business case though. A proper way would be to implement your own merger for the "In Port Block" difference and have that merger do the job of walking the children and merge them along. Please look at the org.eclipse.emf.compare.rcp.merger extension point if you're going to provide your own merger for a difference kind to EMF Compare.

Laurent Goubet
Obeo

[Updated on: Wed, 12 October 2016 04:15] by Moderator

Re: [EMF Compare] Merge action not properly done [message #1763897 is a reply to message #1745534]

Mon, 22 May 2017 13:01

Eclipse User

Hello, I'm coming back to this after a while. I still need some guidance to fix the problem.

Quote:

if we're looking at the left to right direction, we do not "need" to merge the children when we merge the differences adding their parent in the model. That would be the job of the "cascading" filter. If you re-enable that filter the merge will do what you expect it to.

Actually, when I try to re-enable the "Cascading filter" and merge left-to-right I get these 2 different results (both incorrect, btw)

Merge the high level diff (InPortBlock)

The 2 container diffs (InPort and InPortBlock) are merged in the right-side model but the children are not -- so I'm still experiencing the same behavior described above even with the "Cascading filter" enabled
Use "Apply all left changes on the right-hand side"

Now diff InPort i51 is correctly managed (IdentifierReference is copied and the diff maintains its name)! But the high level one is completely lost (??)

Any clue why I'm experiencing this behavior?

Quote:

A proper way would be to implement your own merger for the "In Port Block" difference and have that merger do the job of walking the children and merge them along. Please look at the org.eclipse.emf.compare.rcp.merger extension point if you're going to provide your own merger for a difference kind to EMF Compare

How do I walk through the children of a given difference?
How do I start coding the custom merger through the org.eclipse.emf.compare.rcp.merger extension point? This section in the developer documentation is still under development https://www.eclipse.org/emf/compare/documentation/latest/developer/developer-guide.html#Merging

Thanks in advance.
Best,
--
Matteo

Attachment: mergeLtoR-1.png
(Size: 54.52KB, Downloaded 585 times)
Attachment: mergeLtoR-2.png
(Size: 137.41KB, Downloaded 591 times)

[Updated on: Mon, 22 May 2017 13:05] by Moderator

Re: [EMF Compare] Merge action not properly done [message #1765332 is a reply to message #1763897]

Thu, 08 June 2017 09:53

Eclipse User

Hi Matteo,

I've scheduled a pass on the documentation to try and update what exists for the new code base, and add the sections that are missing, but you are right, this is one of the parts that's currently not available.

I'm still not entirely sure about what's happening in there, especially in that last screenshot. Would you have any way to provide us with a sample test case to reproduce on our side? There seems to be a bug in there, since the cascading differences merging should take place in the described scenario... and even more than that the "Apply all left changes on the right-hand side" really shouldn't behave like it seems it does for you.

Nevertheless, there's been some work accomplished to try and squash the bugs we knew of on the merge process. Could you give a try to the latest version (3.3.1RC3, scheduled to be included in Oxygen)?

Regards,

Laurent Goubet
Obeo

Previous Topic:	Resolving EGit Conflicts with EMF Compare
Next Topic:	EMFCompare and eclipse Che

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 26 16:22:06 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter