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.
EMF Compare/Specifications/ModelMergeUI
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. EMF Compare 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.
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.)