Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

EMF Compare/Specifications/GraphicalComparison

< EMF Compare
Revision as of 09:17, 31 January 2013 by Unnamed Poltroon (Talk) (New page: = Evolution Specification: Graphical Comparison = Current status is '''DRAFT''' == Preamble == ''Summary'': This feature is about all topics around the comparison of graphical objects...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Evolution Specification: Graphical Comparison

Current status is DRAFT

Preamble

Summary: This feature is about all topics around the comparison of graphical objects.

Links to the Bugzilla tickets which are related to the change:

PENDING

Introduction

PENDING This section should contain a summary of the proposed evolution, including why it is needed. Ideally it should be self-contained so that non-developers can get a quick overview of the evolution without reading the detailed specification.

Detailed Specification

The aim is to be the most consistent with the look of the "semantic" comparison (tree).

To put in relief the graphical differences, some decorators should be used.

  • On one hand, it enables to focus on the impacted objects, highlighting them with markers.
  • On the other hand, through phantoms, it enables to locate either the place where objects were deleted or the target location where objects should be added after merging.

On each difference selection, only the related markers will appear.

Below, different cases are detailed.

Non conflicting cases

  • Locally added elements:

AddLocal.png

  • Locally deleted elements:

DeleteLocal.png

  • Remotely added elements:

AddRemote.png

  • Remotely deleted elements:

DeleteRemote.png

  • Local coordinates changes:

ChangeCoordinatesLocal.png

  • Remote coordinates changes:

ChangeCoordinatesRemote.png

  • Local move (and potentially coordinates change):

MoveLocal.png


Conflicting cases

Backward Compatibility and Migration Paths

PENDING Every one of the sections below should be present. Even if there is no corresponding change (for example no API change), it should exist to mention explicitly "This evolution does not change any API."

Metamodel Changes

PENDING Document any change to the Viewpoint 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

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

User Interface Changes

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

Documentation Changes

PENDING List every documentation needing an update here, starting by the New and Noteworthy documentation.

Tests and Non-regression strategy

PENDING 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

PENDING 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