About & Motivation
The Epatch format aims to be for EMF models what the classical patch (originated in the UNIX world, nowadays used with CVS, Subversion, GIT, etc.) is for text files. Creating a classical patch for a model means to create the patch based on the model's XMI file. This has several disadvantages:
- it is not human-readable, since XMI is already difficult to read for the untrained eye.
- it tends to contain a lot of unnecessary information: For example, when the formatting of the XMI file is changed (indentation!) or elements and attributes are interchanged, this typically doesn't mean a change for the model, but a huge change for the classical patch.
- it can not be analyzed by machines: It can not be determined which model elements have been modified, added or removed without having the XMI representation of the to-be-patched model available.
The Epatch format has been contributed (and is further developed) by Moritz Eysholdt (moritz.at.eysholdt.dot.de).
The following operations can be executed...
- The EpatchRecorder records Epatches (buggy), like EMF's ChangeRecorder records ChangeDescriptions.
- The DiffEpatchService creates Epatches from EMF Compare's DiffModels and MatchModels
- CopyingEpatchApplier applies an Epatch by creating a new model which is the patched version of the original model. The original model is untouched.
The Epatch format...
- is bidirectional, i.e. a patch that allows to upgrade model A to model B can as well downgrade model B to model A.
- is meta model (Ecore model) agnostic, i.e. the to-be-patched model's meta models can be Ecore itself or any other Ecore model.
- is self-contained, i.e. Epatches can be read, displayed, processed etc. without having the to-be-patched model available.
- is an EMF model and therefore has an Ecore-based meta model.
- is declarative (as opposed to a sequence of change-operations)
- is able to describe copies and moves of model elements.
- supports multiple resources
- has an optional textual representation, which is based on TMF Xtext