Community
Participate
Working Groups
Once a diff is in a terminal state during a merge session in the comparison editor, the user cannot change his/her decision about the merge direction or accept/reject decision anymore. Trying to merge it into the other direction is a no-op, because the merger won't do anything if the diff is in a terminal state (merged or discarded). Bug 512948 mentions the issue that the actions should at least be disabled, however, ideally they should be functional and allow users to change their decisions. If you consider larger merge scenarios, it is clear that you cannot get every single decision right from the start and not being able to change one's decision may be a serious and very annoying issue for users. Imagine you have done dozens of merge decisions or conflict resolutions already and now realize that one of the earlier accepted changes forced the reject of a change way down the road, which you really don't want to reject. In such scenarios, the only option for users currently is to hit undo until (and thereby loosing all your merge decisions between the one you'd like to change and the current one) until the diff you changed your mind about is unresolved again -- or starting all over again by closing the editor and restarting the comparison.
I am unsure whether this is possible. The merge actions aren't exactly reversible outside of "undo", since we can't determine after the fact what the exact actions taken to resolve a given diff were. For example, the user has accepted a "added element" difference. When he accepted it, some other requirements might have been merged at the same time (in this example, it could have been adding the element to the model, adding its parent, removing another element that was in conflict with it...). How do you determine which of these other diffs need to be undone when the user "wants to go back on his decision" for that diff in particular? What about the equivalent differences? What about the subsets and supersets from UML that require us to change the model in a particular order so as not to screw things up? You are free to pursue this, but this is likely to end up a huge endeavour without real insurance you can actually achieve it.
Yeah, you are right. We've analysed this requirements a couple of weeks ago and tried different approaches. The merger framework is not really designed for supporting this requirement. However, we then settled and succeeded with an approach that is based on the command stack in the comparison editor: when the user changes his/her decision on a diff in the terminal state, we roll-back until (including) this merge command, apply the diff that the user changed his/her mind about again, and then re-apply all the diffs we had to roll-back to get to the one the user changed. This is possible since we know the commands. The beauty of this solution is that it doesn't require extending or changing the mergers themselves. We can rely on the change recorder of the commands to roll back and can extract the information for re-applying the diffs that have already been merged from the command history as the command types are known: merge commands and change commands via the text merge viewer. Unapplying and re-applying is also pretty fast, if we switch off the change notifications to the UI during this process so that it nearly feels immediate. The only disadvantage is that -- in theory -- there could be unknown commands in the command stack, e.g., when the user opens the property view and makes changes to the model with it. Therefore, we check the command history and if we find such commands that we don't understand how to re-apply them, we show a dialog. We have an implementation that we are currently cleaning up and push for review soon.
Yes, using the command stack seems like a viable solution. Let me know when you're done with the change :)
also check 512948 btw... congratulations on two bugs linked to the same feature with such close numbers! :)
(In reply to Laurent Goubet from comment #4) > also check 512948 > > btw... congratulations on two bugs linked to the same feature with such > close numbers! :) Right, I had to double-check three times yesterday wondering how I could end up linking the same bug to itself before I saw that is actually a different (and correct) one :D
New Gerrit change created: https://git.eclipse.org/r/105075
Gerrit change https://git.eclipse.org/r/105075 was merged to [master]. Commit: http://git.eclipse.org/c/emfcompare/org.eclipse.emf.compare.git/commit/?id=84a72adb7861b99d1784359742a47dca33a7c3fa
