[news.eclipse.technology.emft] Re: [EMF Compare] 3 way match

[laurent Goubet <laurent.goubet@xxxxxxx>]

Hi Daniel,

Comments inlined below.

Daniel a écrit :
> Hi,
> Thank you for your work and effort.
>
> My situation is the following: I have 3 Model instances,
> File 1: a base, File 2: a base file with some customisations
> File 3: and another customized (further developed) base file, say new base.
>
>
> I want to get the customisations of File 2 into file 3. Therefore i have 
> to solve some conflicts between those files.
>
> Firstly I want to make sure that this is the right approach for the 3way 
> match.
> I use the ressourceMatch() Method with the 3 Files, than created a Diff 
> out of it.

conflict detection/resolution can only be made when comparing two files 
along with their common ancestor. Thus you can indeed use three-way 
differencing and hope to have interesting results if both your "file3" 
and "file2" are derived from the same base "file1".

MatchService.doResourceMatch() followed by DiffService.doDiff(match) is 
indeed the way to get the differences.

> 1 Question: How do I ignore changes which only affect the order of the 
> elements? (...has been moved from ... to)

We've never implemented a way to ignore differences when comparing, but 
you can do it programmatically when merging by not merging all 
DiffElements instance of "ReferenceOrderChange".

> 2 Question: I get an Diff out of the 3way Matchmodel, but how do i get 
> the origin file of a DiffElement? So how do I know if the change was 
> between file 1 and 2 or 1 and 3?

MatchService.doResourceMatch takes 3 resources as parameter : left, 
right and ancestor (in this order). Talking in terms of version control 
system, "left" is your "local" resource (File3), "right" is the remote 
file (on repository) (File2) and "ancestor" is, well, the common 
ancestor of both files (File1).

With 3-way changes, we'll see "remote" changes and "normal" changes. 
Namely, if you have a Class "Class1" in File1, File2 has renamed this 
class "Class2" and File3 sports a change in which the class is renamed 
"Class3", we'll detect a conflicting change. In the DiffModel, this 
means we'll have a "ConflictingDiffElement" containing an 
"AttributeChange" for the change to "Class3" and a remote 
"AttributeChange" (which method "isRemote() returns true) for the change 
to "Class2".

In opposition, if your File2 had changed the name of your class to 
"Class" and File3 has done the same, no difference would have even been 
detected even though File1 had this class named "Class1".

You can know whether the change had been made in File2 if it is marked 
as a "remote" change.

> 3 Question: I've found a graphic with a "diff extensions" api marked. 
> But where and how do I use this api, and can I use it to manually solve 
> the conflicts with it?

The diff extension API can be used to change the DiffModel itself by 
regrouping differencesin order to "hide" them between a higher 
difference. This doesn't seem to be what you seek.

If you want to merge differences, use the MergeService API (similar to 
MatchService and DiffService, this allows you to merge differences 
easily given the DiffModel). Conflict resolution is only a matter of 
merging the conflicting difference from left to right or right to left 
(in my exemple above, File3 to File2 or File2 to File3 respectively).

We might need to implement a "smarter" conflict resolution API, but for 
now that's what you can access :).

> Thank you in advance,
> greetings
>
> Daniel

Cheers,

Laurent Goubet
Obeo

begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:<a href="http://www.obeo.fr/";>Obeo</a>
email;internet:laurent.goubet@xxxxxxx
url:http://www.obeo.fr
version:2.1
end:vcard