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();

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.

Hi,

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

Hello 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