Revision as of 10:47, 10 April 2013

Evolution Specification: Model merge UI

Current status is DRAFT

Preamble

Model merge UI.

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

• Bug 398361 - Model merge UI

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.

In the Base pack part, we will propose several alternatives for the different parts of the user interface and then make a proposal with some of these choices.

Base Pack

Detailed UI

Global UI

The model merge UI will be split in two parts. The high part will allow to select the differences that will be merged. The low part will show the result of the merge, very similar to the existing content merge viewer of EMF Compare.

This document will propose two alternatives for both parts.

High Part

= Alternative 1 =

The high part of the model merge UI is separate in two parts. The left part (1) : this part shows the difference that we want to merge. It's a reminder on which difference we are merging. This difference is highlighted. The right part (2) : this part shows the differences that will be necessarily and optionally merge. The initial differences from each side are synchronized, it means when we click on the initial difference of the left side, then the right side focuses on the initial difference too.

= Alternative 2 =

The high part of the model merge UI contains only one part, corresponding to the right part (2) of the first alternative.

= Common behavior =

The right part (2) shows the differences that will be necessarily and optionally merge, and the arborescence of these differences. The “mergeable” differences have a checkbox on their side. The checkboxes of differences that will be necessarily merge (the initial difference, and the required differences) are checked and can't be unchecked. If an optional difference is checked, then some new differences can appear and/or become “checkable” (and may be already checked). The initial difference is highlighted with a specific color, in order to remind to the user which initial difference is merging. If a checked difference represents an addition in the target model, the difference label associated will be bold. If a checked difference represents a deletion in the target model, the difference label associated will be cross out. In case of merge a difference from a conflict, then the high part will show all the other differences that belongs to the same conflict (and their respective arbrorescence). The way of merge is displayed in the top right corner of the UI.

Low Part

= Alternative 1 =

The low part of the model merge UI is separate in two parts. The behavior is the same as the existing content merge viewer of EMF Compare, it shows the versions of the compared models.

= Alternative 2 =

The low part of the model merge UI contains only one part. The aim is to focus on what will become the targeted model. It is a preview panel. For example, if the merge is made from right to left, then the low part will display the left model after the merge. If the merge is made from left to right, then the low part will display the right model after the merge.

= Common behavior =

In both cases, the low part is synchronized with the selected difference in the high part. The result of merge will be effective only when the user will click on OK button. The Cancel button cancels all actions made in the merge UI.

Extensions

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