Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Compare » Automatically accept all non-conflicting changes
Automatically accept all non-conflicting changes [message #1749606] Thu, 08 December 2016 14:29 Go to next message
Vlad Acretoaie is currently offline Vlad AcretoaieFriend
Messages: 93
Registered: April 2014
Member
Hi,

I am looking for a way to automatically accept all non-conflicting changes, effectively achieving the same effect as pressing the "Accept All Non-Conflicting Changes" button in the EMF Compare toolbar.

I was able to find out that there is an action for this (MergeAllNonConflictingAction), but I don't know where to invoke it. I guess it should be somewhere in a class extending CompareEditorInput, but any additional suggestions would be greatly appreciated.

Thanks in advance.

Vlad
Re: Automatically accept all non-conflicting changes [message #1749608 is a reply to message #1749606] Thu, 08 December 2016 15:13 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1858
Registered: July 2009
Senior Member
Hi Vlad,

You could also look at how the MergeAllNonConflictingAction is implemented and use the same kind of implementation from your side, as that doesn't really require an UI action if you're trying to call the programmatically.

You'll basically be using the MergeNonConflictingRunnable by telling it what is editable, what the registry of mergers is, and which comparison to merge in whatever direction. You can also what we do in the tests to merge and check if it went well, for example in org.eclipse.emf.compare.tests.merge.TwoWayBatchMergingTest.batchMergeAndAssertEquality(Resource, Resource, Direction) .

Laurent Goubet
Obeo
Re: Automatically accept all non-conflicting changes [message #1749631 is a reply to message #1749608] Thu, 08 December 2016 18:13 Go to previous messageGo to next message
Vlad Acretoaie is currently offline Vlad AcretoaieFriend
Messages: 93
Registered: April 2014
Member
Hi Laurent,

Thank you for your reply. I think your suggestion of looking into the implementation of MergeAllNonConflictingAction is what I need to do.

My current solution is to run MergeAllNonConflictingAction inside the okPressed() method of my CompareEditorInput. The invocation code looks like this:

IMerger.Registry mergerRegistry = EMFCompareRCPPlugin.getDefault().getMergerRegistry();
if (getCompareConfiguration() instanceof IEMFCompareConfiguration) {
    IEMFCompareConfiguration cc = (IEMFCompareConfiguration) getCompareConfiguration();
    MergeAllNonConflictingAction mergeAction = new MergeAllNonConflictingAction(cc, cc.getComparison(), mergerRegistry, MergeMode.ACCEPT);
    mergeAction.run();
}


This works fine as long as at least one difference is shown in the compare editor. If all differences are filtered from view (I currently filter non-conflicting differences), it seems that local changes are lost in the merge process. This is probably the default behavior of the MergeAllNonConflictingAction, since I can also reproduce it by pressing the "Accept All Non-Conflicting Changes" toolbar button.

I will take a look inside MergeAllNonConflictingAction, and see if I can invoke the MergeNonConflictingRunnable in a way that suits my existing workflow.

Cheers,
Vlad
Re: Automatically accept all non-conflicting changes [message #1749948 is a reply to message #1749631] Wed, 14 December 2016 09:03 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1858
Registered: July 2009
Senior Member
Hi,

What do you mean exactly by "local changes are lost" ? Seems to me like the "local" changes shouldn't even be touched when using "ACCEPT" mode, as that means we'll only accept the remote changes. However, that is for Three-way comparisons, in which we have a common ancestor model to use as reference in order to determine what's remote and what's local. In case of a 2-way comparison, all changes are local (the right side is used as a reference) and there cannot be conflicts (there can only be conflicts if there is a common ancestor available). Accepting all changes in such a case will just make your left (local) model a copy of the right (remote) one.

Laurent Goubet
Obeo
Re: Automatically accept all non-conflicting changes [message #1750351 is a reply to message #1749948] Tue, 20 December 2016 10:13 Go to previous messageGo to next message
Vlad Acretoaie is currently offline Vlad AcretoaieFriend
Messages: 93
Registered: April 2014
Member
Hi Laurent,

My question was in the context of a three-way comparison. So the behavior I see when pressing the "Accept All Non-Conflicting Changes" toolbar button and finishing the merge (pressing the "Commit" button in the compare editor window) is that all local changes made to the base model are simply lost. The model that results is a merger between the base and the remote. But this only happens if all changes are non-conflicting. If there is at least one conflicting change, and the conflict is resolved by the user, local non-conflicting changes are kept in the merged model.

I ended up entirely circumventing this issue by only starting the compare editor when there is at least one conflict. When there are no conflicts, I perform a non-conflicting merge using JGit's MergeCommand, and thus never start the compare editor.

Cheers,
Vlad
Re: Automatically accept all non-conflicting changes [message #1750539 is a reply to message #1750351] Thu, 22 December 2016 10:49 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1858
Registered: July 2009
Senior Member
I've raised a bug to track this since it seems highly suspicious.

Thanks for the feedback.
Previous Topic:[Papyrus diagram]Explaination needed of Shape (null) / Connector (null) entries in comparison editor
Next Topic:EMF compare implementation of INavigatable.hasChange()
Goto Forum:
  


Current Time: Wed Sep 19 16:20:48 GMT 2018

Powered by FUDForum. Page generated in 0.02161 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top