Home » Modeling » EMF Diff/Merge » How to get a patch from IComparison's IDifferences?
How to get a patch from IComparison's IDifferences? [message #1447012] |
Fri, 17 October 2014 16:53 |
Nicolas Rouquette Messages: 157 Registered: July 2009 |
Senior Member |
|
|
Using the EMF Diff/Merge programmatic support for comparing models,
I would like to convert the differences into a patch model.
That is, I'm interested in a variant of the usage shown in the doc:
https://wiki.eclipse.org/EMF_DiffMerge/Programmatic_Usage
Resource rOrig = ...; // the original model
Resource rChanged = ...; // the original model, modified, saved as a different resource
IEditableModelScope targetScope = new FragmentedModelScope(rOrig);
IEditableModelScope referenceScope = new FragmentedModelScope(rChanged);
IComparison comparison = new EComparisonImpl(targetScope, referenceScope);
comparison.compute(aMatchPolicy, aDiffPolicy, aMergePolicy, aProgressMonitor);
Collection<IDifference> differences = comparison.getRemainingDifferences();
According to the doc, there are 3 concrete differences to handle:
Quote:
There are only 3 essential types of difference (subtypes of IDifference):
Presence of an unmatched element (IElementPresence): an element in a scope has no match in the opposite scope.
Presence of an unmatched reference value (IReferenceValuePresence): a matched element references another element in only one scope.
Presence of an unmatched attribute value (IAttributeValuePresence): a matched element owns a certain attribute value in only one scope.
I would like to save these differences in such a way that, if applied to rOrig, would result in a model that would be comparatively identical to rChanged.
Can this be done with EMF Diff/Merge or do I have to do this with the EMF Compare somehow?
- Nicolas.
|
|
| |
Re: How to get a patch from IComparison's IDifferences? [message #1447060 is a reply to message #1447026] |
Fri, 17 October 2014 18:31 |
Nicolas Rouquette Messages: 157 Registered: July 2009 |
Senior Member |
|
|
Felix Dorner wrote on Fri, 17 October 2014 13:20Hi,
On 17/10/2014 18:53, Nicolas Rouquette wrote:
> I would like to save these differences in such a way that, if applied to
> rOrig, would result in a model that would be comparatively identical to
> rChanged.
Save as in "Save to a File" I don't think you can, see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=416493
Saving the raw IDifferences would have persistent references to both models.
What I'm looking for is the Diff/Merge equivalent of the old EPatch service:
https://wiki.eclipse.org/EMF_Compare/Epatch
In this example, having computed the differences between rOrig and rChanged (= rOrig + modifications), I need a patch file: rOrig2Changed.patch, such that applying this patch to rOrig would result in a model that is comparatively identical to rChanged.
That is, the patch, rOrig2Changed.patch, can only refer to elements in rOrig only.
- Nicolas.
|
|
| |
Re: How to get a patch from IComparison's IDifferences? [message #1449888 is a reply to message #1448653] |
Tue, 21 October 2014 23:24 |
Nicolas Rouquette Messages: 157 Registered: July 2009 |
Senior Member |
|
|
Thanks Olivier for your comments.
I looked at Epatch; however, it was designed to work with the EMF.compare framework. Given that EMF.compare and EMF.diffmerge have subtle and important differences, I doubt that adapting the Epatch algorithms to EMF.diffmerge would produce reliable results.
About the problem...
At the OMG, Yves Bernard & I lead a working group "Tool Infrastructure WG" to simplify & automate the labor-intensive process of revising OMG specifications (e.g. UML, SysML, etc...) So far, every revision of OMG specifications (e.g. UML, SysML, OCL, ...) requires writing issue resolution documents that detail all of the changes to be made to a specification. Writing such issue resolution documents is the most labor-intensive, error-prone and discouraging aspect of working on an OMG task force.
So, our strategy is to radically simplify the most expensive aspect of this process.
Instead of writing an issue resolution document manually as currently done, the idea is to generate an issue resolution document from the differences made to a (big) model of *everything* that pertains to a given OMG specification. By *everything*, we mean a model of the specification document (incl. figures thanks to UML 2.5 DI) and of the so-called "machine-readable" files which are typically UML models.
In terms of EMF diff/merge, this means that generating an issue resolution document would involve the following process:
- branch the model of the specification to draft a resolution for a particular issue.
say we have model M1
- drafting the resolution means edit the model as needed to resolve the issue
say we save the modified model as M2
- generating the issue resolution then means:
-- compute the differences from M1 to M2
(I know how to do that thanks to the EMF diff/merge wiki page)
-- turn the EMF diff/merge model of differences & matches into a "patch" model
By "patch" model, I mean a list of changes that, if applied to M1, would produce a model that should have no differences w.r.t. M2
A "patch" model would be an ordered sequence of "patch" operations: add, move, delete, change, ..
- Nicolas.
Olivier Constant wrote on Mon, 20 October 2014 04:43Hello Nicolas,
Your need is clear. There is currently no concept of patch in EMF Diff/Merge, although the topic pops up regularly.
The thing is, there are several possibilities regarding the definition of a patch in EMF Diff/Merge. Each would solve a slightly different set of needs and imply different usage scenarios.
So out of curiosity, are you willing to tell us about the origin of your need? Reporting a change between branches in a version control setting? Having a stronger separation between the diff and merge phases for process-related or performance reasons? Something else?
I don't know about the targeted usage context or maintenance state of Epatch but you may ask in the related forum.
Olivier
|
|
|
Re: How to get a patch from IComparison's IDifferences? [message #1451336 is a reply to message #1449888] |
Thu, 23 October 2014 17:28 |
Olivier Constant Messages: 106 Registered: January 2012 |
Senior Member |
|
|
OK, if I summarize my understanding:
Your main purpose is to generate issue resolution documents from the original (M1) and revised (M2) models of the specification document, where the generation is automated as much as possible.
Your idea is to compute a comparison of M1 and M2, extract a model of the changes (let's say MC), and use some document generator to generate most of the issue resolution document from MC.
Can we refine that a bit?
- Is it important that MC be serialized?
- If so, does it really have to be self-contained like a patch, or is it allowed to refer to elements in M1, meaning that it can only be exploited if it goes along with M1?
- Similarly, is MC allowed or not to refer to elements in M2 (e.g., elements added in M2)?
- Is it important that MC be "applicable" like a patch, i.e., that you are able to select M1 and MC and automatically obtain M2? Cannot you just replace M1 with M2?
- Does MC have to contain information at a user level of abstraction, or can it be more technical, in which case the gap between the technical and user levels would be dealt with by the document generator?
Olivier
|
|
| | |
Goto Forum:
Current Time: Fri Apr 26 13:56:14 GMT 2024
Powered by FUDForum. Page generated in 0.03446 seconds
|