Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EMF Compare/Specifications/ModelMergeUI"

(From Left to Right)
 
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
{{Template:EMF Compare Archive Notice}}
 +
 
= Evolution Specification: Model merge UI =
 
= Evolution Specification: Model merge UI =
  
Current status is '''DRAFT'''
+
Current status is '''MERGED'''
  
 
== Preamble  ==
 
== Preamble  ==
Line 10: Line 12:
  
 
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=398361 Bug 398361] - Model merge UI
 
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=398361 Bug 398361] - Model merge UI
 +
*[https://git.eclipse.org/r/#/c/13902/ Review 13902]
  
 
== Introduction  ==
 
== Introduction  ==
Line 23: Line 26:
 
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.
 
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.
+
=== User interface ===
  
=== Base Pack ===
+
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.
  
==== Global UI  ====
+
It exists two cases of comparison :
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.
+
* one side of the merge is in a read-only mode
 +
* both sides are "writeable"
  
[[Image:EMFCompare2_MergeUI_GlobalUI.png|alt GlobalUI]]
+
==== When one side is in a read-only mode ====
  
This document will propose two alternatives for both parts.
+
Four buttons will be added to the structure merge viewer toolbar.
  
==== High Part ====
+
[[Image:EMFCompare2_MergeUI_Icon_Accept.png|EMF Compare Accept icon]]
 +
[[Image:EMFCompare2_MergeUI_Icon_Reject.png|EMF Compare Reject icon]]
 +
[[Image:EMFCompare2_MergeUI_Icon_AcceptAll.png|EMF Compare Accept All icon]]
 +
[[Image:EMFCompare2_MergeUI_Icon_RejectAll.png|EMF Compare Reject All icon]]
  
===== Alternative 1 =====
+
* Accept button : accept the difference and apply it immediately.
The high part of the model merge UI is separate in two sub-parts.
+
* Reject button : reject the difference and apply it immediately.
The left sub-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.
+
* Accept all non-conflicting changes button : accept all non-conflicting differences and apply them immediately.
The right sub-part (2) : this part shows the differences that will be necessarily and optionally merge.  
+
* Reject all non-conflicting changes button : reject all non-conflicting differences and apply them immediately.
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.
+
The initial difference is highlighted with a specific color, in order to remind to the user which initial difference is merging.
+
  
[[Image:EMFCompare2_MergeUI_HighPart_v1.png|alt High Part Alternative 1]]
+
A right-click menu will also be available with the accept and reject actions.
  
===== Alternative 2 =====
+
[[Image:EMFCompare2_MergeUI_Icon_RightClickMenu_AcceptReject.png|EMF Compare Reject All icon]]
The high part of the model merge UI contains only one sub-part, corresponding to the right sub-part (2) of the first alternative.
+
The initial difference is highlighted with a specific color, in order to remind to the user which initial difference is merging.
+
  
[[Image:EMFCompare2_MergeUI_HighPart_v2.png|alt High Part Alternative 2]]
+
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
  
===== Alternative 3 =====
+
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).
  
The alternative 3 uses a browsing technique named [[http://en.wikipedia.org/wiki/Miller_Columns Miller Columns]] that can be applied to tree structures.
+
* '''accept a local change'''
  
The high part of the model merge UI contains a dynamic number of sub-parts.
+
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.
  
The left initial sub-part (1), contains the initial difference selected in the structure merge viewer of the EMF Compare UI.
+
* '''accept a remote change'''
  
The center sub-part (2), contains the differences that will be necessarily merge with selected differences in the previous sub-part (1), and the differences that could be optionally merged.
+
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.
  
The right sub-part (3), contains the differences that will be necessarily merge with selected differences in the previous sub-part (2), and the differences that could be optionally merged.
+
* '''reject a local change'''
And so on...
+
  
Thus, the high part contains the needed numbers of sub-parts, which or added/deleted dynamically. At the launching of the model Merge UI, the right sub-part doesn't exists. It is only a user will select a difference in the center sub-part that the right sub-part will be potentially created.
+
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.
  
The selection of a checked difference in a sub-part N is synchronized with the required and optional differences associated in the sub-part N+1.
+
* '''reject a remote change'''
  
[[Image:EMFCompare2_MergeUI_HighPart_v3.png|alt High Part Alternative 3]]
+
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.
  
===== Common behavior =====
+
==== When both sides are "writeable" ====
The right sub-part (2) and the sub-parts of the alternative 3 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 tree item that have a checkboxes have a right-click menu with two items : select/check and unselect/unchecked difference.
+
*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).
+
*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.
+
  
Some behavior needs to be validated:
+
Four buttons will be added to the structure merge viewer toolbar.
*A click on a difference focuses on a difference.
+
*A double-click on an unchecked difference check the difference.
+
*A double-click on a checked difference uncheck the difference.
+
  
==== Low Part ====
+
[[Image:EMFCompare2_MergeUI_Icon_LeftToRight.png|EMF Compare Left to Right icon]]
 +
[[Image:EMFCompare2_MergeUI_Icon_LeftToRightAll.png|EMF Compare Right to Left icon]]
 +
[[Image:EMFCompare2_MergeUI_Icon_RightToLeft.png|EMF Compare Left to Right All icon]]
 +
[[Image:EMFCompare2_MergeUI_Icon_RightToLeftAll.png|EMF Compare Right to Left All icon]]
  
===== Alternative 1 =====
+
* Copy Current change from Right to Left button : merge the current difference from Right to Left.
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.
+
* 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.
  
[[Image:EMFCompare2_MergeUI_LowPart_v1.png| Low Part Alternative 1]]
+
==== Implications panel ====
  
===== Alternative 2 =====
+
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.
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.
+
  
If a selected difference in the high part represents an addition in the target model, the difference label associated in the low part will be bold.  
+
[[Image:EMFCompare2 MergeUI ImplicationsPanel.png|EMF Compare Implications panel]]
  
If a selected difference in the high part represents a deletion in the target model, the difference label associated in the low part will be cross out.
+
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).  
  
The alternatives 2 low part is not fully synchronized with the selected difference in the high part. The preview button synchronized the low part with the selected difference(s) in the high part.
+
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.
  
The Preview action will display the merge result of checked differences. Then, when a user focus on a checked difference, the low part display the result after merge for this difference.
+
[[Image:EMFCompare2_MergeUI_Icon_RadioLeftToRight.png|EMF Compare Radio Left to Right icon]]
 +
[[Image:EMFCompare2_MergeUI_Icon_RadioRightToLeft.png|EMF Compare Radio Right to Left icon]]
  
[[Image:EMFCompare2_MergeUI_LowPart_v2.png| Low Part Alternative 2]]
 
  
The reason of this preview button is that a full synchronization between high & low part will slow the UI. The display of this preview is an expansive task in terms of time and resources. If a user select several differences in the high part in a short lapse of time, the low part will take probably too much time to react in time to these successive selections. If the UI freeze, it will result in a bad experience for the user.
+
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.
  
Some behavior needs to be validated:
+
[[Image:EMFCompare2_MergeUI_Icon_ComboLeftToRight.png|EMF Compare Combo Left to Right icon]]
 
+
[[Image:EMFCompare2_MergeUI_Icon_ComboRightToLeft.png|EMF Compare Combo Right to Left icon]]
*After a Preview action (a click on the Preview button), what happens in the low part if a user checks some new differences, or unchecks then re-checks differences ? The low part will be desynchronized. Should we deactivate the low part until the user click on the Preview button again ?
+
 
+
===== Common behavior =====
+
 
+
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.
+
 
+
Some behavior needs to be validated:
+
 
+
*The low part change after a simple click (focus) or a double-click on a difference in the high part ? Or something else ? If it is a double-click, is it compatible with the check/uncheck double-click action in the high part ?
+
*What the low part should display on a non-checked item ? On a match ?
+
 
+
==== Proposal ====
+
The choices for the proposal are alternatives 2 for both high & low parts.
+
For the high part, alternative 2 is more simple than alternative 1 because it has one panel less. Furthermore, information lost with alternative 1, are still here in alternative 2. The initial difference is highlighted with a specific color to remind to the user which difference was initially involved for the merge.
+
For the low part, alternative 2 better allow to focus on the result after merge.
+
 
+
[[Image:EMFCompare2_MergeUI_Proposal.png|alt Proposal]]
+
 
+
==== Integration with EMF Compare ====
+
This new graphical user interface is integrated with the buttons « Copy Current Change from Left to right » and « Copy Current Change from Right to Left ». When a user click on one of these buttons, then the interface is launched.
+
 
+
[[Image:EMFCompare2_MergeUI_Integration_With_EMFCompare.png|alt Integration with EMF Compare]]
+
 
+
=== Examples ===
+
 
+
The following emf compare model will serve as example for the following use cases. It is a result of a 3-way comparison.
+
 
+
[[Image:EMFCompare2_MergeUI_SampleModel.png|alt Sample Model]]
+
 
+
You can found the models use for comparison here :
+
https://github.com/Obeo/emf.compare.acceptance.tests/blob/master/tests/emf.compare.q7.tests/resources/Library.zip
+
 
+
==== Merge of extlibrary \ Book → CirculatingItem \ TitledItem [eSuperTypes add] ====
+
 
+
===== From Left to Right =====
+
There are no further consequences about merging TitledItem [eSuperTypes add] of Book → CirculatingItem from left to right, because it goes to delete TitledItem from the list of eSuperTypes of Book.
+
The item TitledItem [eSuperTypes add] is the initial difference we want to merge, so it is highlighted with a specific color. It is checked and locked in the high part. It is crossed out in the low part because the action of merge represents a deletion in the target model.
+
The subtitle and title attributes of Book are not displayed because they are not involved in the merge of the initial difference.
+
 
+
[[Image:EMFCompare2_MergeUI_Ex1_LtoR.png|alt Example 1 Left to Right]]
+
 
+
===== From Right to Left =====
+
There is one consequence about merging TitledItem [eSuperTypes add] of Book → CirculatingItem from right to left. It goes to add TitledItem from the list of eSuperTypes of Book, so the eClassifier TitledItem will be necessarily merge too.
+
The item TitledItem [eSuperTypes add] is the initial difference we want to merge, so it is highlighted with a specific color. It is checked and locked in the high part. It is bold in the low part because the action of merge represents an addition in the target model. The item TitledItem [eClassifiers add] is checked, locked and bold too.
+
The title attribute of TitledItem [eClassifiers add] and EString type of title are displayed and available to check, because they are sub-differences of a checked difference. If the user checks EString, then title will be automatically checked and locked.
+
 
+
[[Image:EMFCompare2_MergeUI_Ex1_RtoL.png|alt Example 1 Right to Left]]
+
 
+
==== Merge of extlibrary \ Periodical -> Item [eClassifiers delete] ====
+
 
+
===== From Left to Right =====
+
There are several consequences about merging Periodical [eClassifiers delete] from left to right. It goes to delete Periodical from the list of eStructuralFeatures of extlibrary, and all of these sub-differences.
+
The tree item Periodical [eClassifiers delete] is the initial difference we want to merge, so it is highlighted with a specific color. It is checked and locked in the high part. It is crossed out in the low part because the action of merge represents a deletion in the target model. All of these sub-differences are checked, locked and crossed out too.
+
The tree item Periodical → Item, TitledItem [eSuperTypes add] is displayed and checked, because it is conflicting with the deletion of Periodical [eClassifiers delete]. You must delete Periodical → Item, TitledItem [eSuperTypes add] if you delete Periodical [eClassifiers delete].
+
 
+
[[Image:EMFCompare2_MergeUI_Ex2_LtoR.png|alt Example 2 Right to Left]]
+
 
+
===== From Right to Left =====
+
There are no further consequences about merging Periodical [eClassifiers delete] from right to left. It goes to add Periodical from the list of eStructuralFeatures of extlibrary.
+
The tree item Periodical [eClassifiers delete] is the initial difference we want to merge, so it is highlighted with a specific color. It is checked and locked. It is bold because the action of merge represents an addition in the target model. All of these sub-differences are displayed and available to check.
+
The tree item Periodical → Item, TitledItem [eSuperTypes add] is displayed, because it is in the same conflict group with Periodical [eClassifiers delete], but in this case there is no conflict between them.
+
 
+
[[Image:EMFCompare2_MergeUI_Ex2_RtoL.png| Example 2 Left to Right]]
+
 
+
===== Alternative 2 =====
+
 
+
If you check the tree item Periodical → Item, TitledItem [eSuperTypes add], then the tree item Magazine → Periodical [eClassifiers add] will be checked and locked.
+
 
+
[[Image:EMFCompare2_MergeUI_Ex2_RtoL2.png| Example 2 Left to Right step 2]]
+
 
+
If you check the tree item TitledItem [eSuperTypes add], then the tree item TitledItem [eClassifiers add] will be displayed, checked and locked. Its sub-differences will be displayed too.
+
 
+
[[Image:EMFCompare2_MergeUI_Ex2_RtoL3.png| Example 2 Left to Right step 3]]
+
 
+
===== Alternative 3 =====
+
 
+
The initial difference is selected in the left sub-part. The center sub-part contains the item Periodical → Item, TitledItem [eSuperTypes add] because it is a difference that belongs to the same conflict group than the initial difference. But it is not checked.
+
 
+
[[Image:EMFCompare2_MergeUI_Ex2_RtoL_Step2_v3.png| Example 2 Left to Right step 2 - alternative 3]]
+
 
+
In the central sub-part, if you check the the item Periodical → Item, TitledItem [eSuperTypes add], then a new sub-part will be created at the right of the central sub-part.
+
This right sub-part will contain the required differences associated with the item Periodical → Item, TitledItem [eSuperTypes add]. In this case the required difference is his parent difference.
+
 
+
[[Image:EMFCompare2_MergeUI_Ex2_RtoL_Step3_v3.png| Example 2 Left to Right step 3 - alternative 3]]
+
 
+
=== Extensions ===
+
The following items are additional features that are not mandatory to make the user interface functional but will be helpful to improve the user experience. These extensions are sorted by priority level.
+
 
+
==== Multi-selection ====
+
 
+
With the base pack, it is only possible to select one element before launching the model merge UI. With the "multi-selection" feature, it will be possible to select several elements before launching the model merge UI. Then, in the model merge UI, there will be several initial differences selected.
+
 
+
==== Expert mode ====
+
 
+
With the base pack, the new model merge UI will be launched every time a user will click on the “Copy Current Change from Right to Left” button or the “Copy Current Change from Left to Right” button. With the “Expert Mode” feature, a new tool will be added to the structure merge viewer toolbar, in order to let the user choose if he wants to use the new model merge UI or not. It counts only for the non-conflicting differences.
+
 
+
==== Shaded colors ====
+
 
+
The “shaded colors” feature improves the user feedback in the high part. Remember in the [[http://wiki.eclipse.org/EMF_Compare/Specifications/ModelMergeUI#Common_behavior common behavior]] section : “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.”
+
With the “shaded colors” feature, all the checked differences will be highlighted, and each time a user will select a new difference in the UI, then this new difference and the required differences associated with it will be highlighted with a new color. Thus, the user can better distinguish the correlation between differences.
+
 
+
==== Filters ====
+
 
+
With this feature, the filters tool will be accessible in the model merge UI.
+
 
+
==== Merge both sides ====
+
 
+
This extension will allow to merge to both sides in model merge UI, which is not possible with the base pack who only authorize to merge differences to the same side as the initial difference.
+
+
That means the checkboxes would have 3 states :
+
*unchecked
+
*left side
+
*right side
+
 
+
The initial difference will be not locked anymore. It will be possible to change its side of merge.
+
 
+
This extension is not compatible with the Switch button extension.
+
 
+
==== Switch button ====
+
 
+
Suppose you want to merge a difference from left to right, but you click on the “Copy Current Change from Right to Left” button, or you simply just want to see what is the result on the other way. With the base pack, it is not possible to switch the way of the comparison in the model merge UI. Then, you have to click cancel and relaunch the UI by clicking on the appropriate button.
+
An extension will allow to switch the way of the comparison in the model merge UI and thus avoid to users to relaunch the UI when they want to see what's happening on the other way. An icon will be added to the toolbar located on the top of the UI. The switching action will canceled all the differences already checked.
+
 
+
This extension is not compatible with the Merge both sides extension.
+
 
+
==== Content merge viewer retractable ====
+
 
+
With this feature, the low part of the model merge UI will be retractable. Once the low part hidden, the high part will occupy the whole UI. In case of big models, it will be easier for the user to have a larger space to select the differences he wants to merge.
+
 
+
==== Display more differences ====
+
 
+
Remember in the [[http://wiki.eclipse.org/EMF_Compare/Specifications/ModelMergeUI#Common_behavior common behavior]] section : “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 idea of this “Display more differences” feature is to show all differences linked indirectly with a selected difference. In other words, in case of selecting a difference that is a containment reference, then the non-containment references referencing this containment reference will be displayed.
+
Suppose you want to merge the tree item TitledItem [eClassifiers add] from right to left.
+
With the base pack, the merge UI looks like this:
+
 
+
[[Image:EMFCompare2_MergeUI_Extension_Display_1.png|alt Without Extension]]
+
 
+
Cause, the merge of this difference has no consequences on other differences, the tree displays just the initial difference and its sub-differences.With the “Display more differences” feature, all the non-containment references referencing the initial difference will be displayed:
+
 
+
[[Image:EMFCompare2_MergeUI_Extension_Display_2.png|alt With Extension]]
+
  
 
== Backward Compatibility and Migration Paths  ==
 
== Backward Compatibility and Migration Paths  ==
Line 283: Line 141:
 
TODO.
 
TODO.
 
(Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.)
 
(Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.)
 
[[Category:EMF Compare]]
 

Latest revision as of 11:50, 5 March 2014

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

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.

EMF Compare Accept icon EMF Compare Reject icon EMF Compare Accept All icon EMF Compare Reject All icon

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

EMF Compare Reject All icon

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.

EMF Compare Left to Right icon EMF Compare Right to Left icon EMF Compare Left to Right All icon EMF Compare Right to Left All icon

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

EMF Compare Implications panel

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.

EMF Compare Radio Left to Right icon EMF Compare Radio Right to Left icon


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.

EMF Compare Combo Left to Right icon EMF Compare Combo Right to Left icon

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

Back to the top