EMF Compare/Specifications/ModelMergeUI

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

Evolution Specification: Model merge UI

Current status is MERGED

Preamble

Model merge UI.

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

• Bug 398361 - Model merge UI
• Review 13902

Introduction

The goal is to provide a graphical user interface that will guide the user through the merge and conflict resolution process and that will let him choose how to solve a conflict whenever possible.

Detailed Specification

When the user wants to merge a difference, he can be confused with the numerous other differences that may need to be merged. This is caused by the dependencies between differences. For instance, if the user tries to merge the addition of a state in an activity diagram, he also has to merge the addition the activity diagram first (if it did not previously exist).

Currently, EMF Compare displays the list of all detected differences that can be merged, but it does nothing to make the links between differences (requirements, equivalences...) explicit. We should offer a preview of the merge of each required difference and allow the user to merge the dependencies step by step. EMF Compare should also give the user the ability to choose how to merge independent conflicts.

We will provide a graphical user interface that will guide the user through the merge and conflict resolution process and that will let him choose how to solve a conflict whenever possible.

User interface

When a user select a difference in the structure merge viewer, the differences required for the merge of this difference will be highlighted in green. If some differences will become "unmergeable", they will be highlighted in red.

It exists two cases of comparison :

• one side of the merge is in a read-only mode
• both sides are "writeable"

When one side is in a read-only mode

Four buttons will be added to the structure merge viewer toolbar.

• Accept button : accept the difference and apply it immediately.
• Reject button : reject the difference and apply it immediately.
• Accept all non-conflicting changes button : accept all non-conflicting differences and apply them immediately.
• Reject all non-conflicting changes button : reject all non-conflicting differences and apply them immediately.

A right-click menu will also be available with the accept and reject actions.

There are four kind of actions in this mode:

• accept a local change
• accept a remote change
• reject a local change
• reject a remote change

For example, we'll suppose that you are trying to use EMF Compare on models shared under git. If you're launch a 3-way comparison of your local model with the HEAD Revision, the HEAD revision model is in a read-only mode. You can only merge differences from the HEAD Revision model to your local model (from Right to Left).

• accept a local change

The local change will be kept. For an addition change, it is equal to add the local element in your local model. For a deletion change, it is equal to delete the remote element in your local model.

• accept a remote change

The remote change will be kept. For an addition change, it is equal to add the remote element in your local model. For a deletion change, it is equal to delete the local element in your local model.

• reject a local change

The remote change will be kept. For an addition change, it is equal to delete the local element in your local model. For a deletion change, it is equal to add the remote element in your local model.

• reject a remote change

The local change will be kept. For an addition change, it is equal to delete the remote element in your local model. For a deletion change, it is equal to add the local element in your local model.

When both sides are "writeable"

Four buttons will be added to the structure merge viewer toolbar.

• Copy Current change from Right to Left button : merge the current difference from Right to Left.
• Copy Current change from Left to Right button : merge the current difference from Left to Right.
• Copy all non-conflicting changes from Right to Left button : merge all non-conflicting differences from Right to Left.
• Copy all non-conflicting changes from Left to Right button : merge all non-conflicting differences from Left to Right.

Implications panel

An implication panel will be available from the right part of the structure merge viewer. This panel will show the consequences of the merge of a difference. When a difference is selected in the structure merge viewer, two lists will be displayed in the panel: the list of required differences to merge with the current difference, and the list of impossible differences to merge after merging the current difference. This panel will be retractable.

If both sides are "writeable", you have to choose the way of merge (Right to Left or Left to Right) in order to display the appropriate differences in the implications panel. The solution to choose the way will be a radio button or a combo. A default way of merge will be set (from Right to Left).

If it will be a radio button, only one radio button will be active at a time. If the Left to right radio button is active, the icons Right to Left will be inactive and vice versa.

If it is the combo, a click on the button will switch from Left to right to Right to Left and vice versa. The arrow on the right side of the combo will propose two menu items (Left to Right and Right to Left). If the Combo Left to right radio button is selected, the icons Right to Left will be inactive and vice versa.

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.)