Implement merge with basic conflict handling (LeftToRIght & RightToLeft)

[jbsarrodie]

I've finally tested coArchi 2 and looked at how RefreshModelAction handles merge. When some conflicts are detected at git level, or if a successful git merge led to an invalid model, the merge is managed by MergeHandler#handle3WayMerge(), mainly through these lines of code:

IComparisonScope scope = new DefaultComparisonScope(ourModel, theirModel, baseModel);
Comparison comparison = EMFCompare.builder().build().compare(scope);
List<Diff> differences = comparison.getDifferences();

Registry mergerRegistry = RegistryImpl.createStandaloneInstance();
IBatchMerger merger = new BatchMerger(mergerRegistry);
        
// Copy theirs into ours
merger.copyAllRightToLeft(differences, new BasicMonitor());

From my tests, this leads to local (ie. Left) changes being discarded because only changes done on the remote end (ie. Right) are applied to the Common Ancestor and then saved as the Left model. So it seems we have to implement the following (loosely based on this code and this one too):

1. Select non conflicting changes coming from Left (using a filter based on and(fromSide(DifferenceSource.LEFT), not(hasConflict(ConflictKind.REAL)))) and applying them to common Ancestor (using BatchMerger.copyAllLeftToRight())
2. Select non conflicting changes coming from Right (using a filter based on and(fromSide(DifferenceSource.RIGHT), not(hasConflict(ConflictKind.REAL)))) and applying them to common Ancestor (using BatchMerger.copyAllRightToLeft())
3. Merge conflicting changes:
4. Select conflicting changes
5. Ask the user what to do with them in a global way (keep "our" changes or keep "their" changes)
6. Based on answer to previous question, call either BatchMerger.copyAllLeftToRight() for "our" or BatchMerger.copyAllRightToLeft() for "their".

[jbsarrodie]

Another remark related to my tests: when renaming a concept which is used on a view, in the list of differences, I get a change on the concept (expected), but also a change on DiagramModelArchimateObject instances related to this concept. Maybe there is some tuning to be done so that EMF Compare doesn't take such EMF classes into account.

[Phillipus]

Another remark related to my tests: when renaming a concept which is used on a view, in the list of differences, I get a change on the concept (expected), but also a change on DiagramModelArchimateObject instances related to this concept. Maybe there is some tuning to be done so that EMF Compare doesn't take such EMF classes into account.

See #10

[jbsarrodie]

@Phillipus I've implemented a basic merge operation which works as intended.

Still to be done:

• Filter Diffs which should never been applied, such as those related to DiagramModelArchimateObject#name
• Check what happens when solving conflicts in a way that would lead to a non integral model
• Some nice UI :-)