EMF Compare/Specifications/MoreAccessibleMergeActions

THIS PAGE IS ARCHIVED. IT IS PROBABLY OUTDATED AND WILL NOT BE UPDATED

Evolution Specification: More accessible merge actions

Current status is ARCHIVED

Preamble

More accessible merge actions.

_Relevant tickets_ (links to the Bugzilla tickets which are related to the change):

• Bug 398366 - More accessible merge actions
• Review 13902

Introduction

EMF Compare will add merge facilities as right-click actions in both kind of viewers and also in a toolbar on the top right, before save, filter and group actions. EMF Compare will also enhance the way merged differences are displayed.

Detailed Specification

Currently, it is not possible to trigger merge operation from the structure merge viewer. The only way to update the “merge” actions is to double-click the structure viewer (top half of the compare editor) so that the content viewers (bottom half of the compare editor) are updated. In other words, only the content viewer can update the merge actions. EMF Compare will add merge facilities as right-click actions in both kind of viewers and also in a toolbar on the top right, before save, filter and group actions. The actions will be labelled as follow:

• accept change
• reject change

Their behavior will change whether we are currently on a two-way comparison or a three-way comparison. During three-way comparisons, the source of the change will be taken into account to react appropriately. EMF Compare will also enhance the way merged differences are displayed. Currently they are only grayed out and the icon is changed, but the user has no way to know how the difference has been merged: which side did it originate from, which side was it merged to or if it has been rejected or accepted altogether. The decorator will reflect this information.

Backward Compatibility and Migration Paths

Metamodel Changes

TODO. (Document any change to the metamodel. If they require a migration operation, mention it and describe the general idea of how migration process. If any information can be lost during the migration, mention it clearly. If validation rules must be added/modified, mention it also.)

API Changes

TODO. (List every API addition, removal and deprecation. For each removal and deprecation, indicate the migration path for existing code.)

User Interface Changes

TODO. (List every user-visible change in the interface. Here "user" includes not only end-users but also developpers.)

Documentation Changes

TODO. (List every documentation needing an update here, starting by the New and Noteworthy documentation.)

Tests and Non-regression strategy

TODO. (This part of the document should describe the strategy to use to correctly test the evolution and guarantee the non-regression.)

Implementation choices and tradeoffs

TODO. (Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.)