The EMF Diff/Merge project is part of&nbsp;[http://www.eclipse.org/projects/project.php?id=modeling.emf EMF].

The EMF Diff/Merge project is part of&nbsp;[http://www.eclipse.org/projects/project.php?id=modeling.emf EMF].

+

+

== Principle ==

+

+

The usage process is illustrated by the figure below. First, a comparison is created based on the models to compare. The differences between those models are computed according to given policies. Then, as long as differences remain, any subset of these differences can be selected for merging. Every time, predefined consistency rules and user-defined policies are used to compute the minimal superset of differences that must be merged to preserve consistency. The user may decide whether to confirm or cancel the merge of the whole set of differences.<br>

Revision as of 10:32, 6 November 2012

Contents

Introduction

EMF Diff/Merge is a diff/merge tool for models.

Merging models is a common need in model-based activities, not only for version control but for model manipulation in general. However, merging models is much more complex than merging source code. Since EMF models are rich data structures with constraints and behavior, merging them consistently is a delicate problem.

EMF Diff/Merge aims to help solve that problem. The tool currently satisfies the following requirements:

The consistency of the model being merged is preserved whenever possible, by automatically merging interdependent differences together.

The order in which differences are merged has no impact.

The global impact of a merge can be determined beforehand (picture below).

Undo/redo of merges is supported.

Comparison can be performed on any arbitrary model scope for better versatility and scalability.

The scope of EMF Diff/Merge covers:

A lightweight, configurable engine for comparing and merging EMF models in 2-way and 3-way (with common ancestor) configurations.

Matching of model elements by ID, where an ID can be any "signature" that uniquely identifies the element within its scope: Ecore ID, XML ID, qualified name, location in model tree, etc.

A simple GUI with reusable UI components.

The final goal is to obtain a mature, versatile software building block for multiple usages: version control, incremental model transformations, model refactoring, etc.

Principle

The usage process is illustrated by the figure below. First, a comparison is created based on the models to compare. The differences between those models are computed according to given policies. Then, as long as differences remain, any subset of these differences can be selected for merging. Every time, predefined consistency rules and user-defined policies are used to compute the minimal superset of differences that must be merged to preserve consistency. The user may decide whether to confirm or cancel the merge of the whole set of differences.