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 13:52  |
 Matteo M.
Messages: 40
Registered: May 2012 |
Member |
|
|
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.
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":
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 618 times)-
Attachment: merge.png
(Size: 8.38KB, Downloaded 582 times)
[Updated on: Wed, 05 October 2016 14:15] Report message to a moderator |
|
| | |
| Re: [EMF Compare] Merge action not properly done [message #1745534 is a reply to message #1745471] |
Wed, 12 October 2016 08:13  |
|
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 08:15] Report message to a moderator |
|
| |
| Re: [EMF Compare] Merge action not properly done [message #1765332 is a reply to message #1763897] |
Thu, 08 June 2017 13:53 |
|
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
|
|
|
Goto Forum:
Current Time: Thu Apr 25 07:17:53 GMT 2024
Powered by FUDForum. Page generated in 0.03340 seconds |
] 
Search
Help
Register
Login
Home
