plugins/org.eclipse.emf.compare.doc/doc/developer/Architecture.html - emfcompare/org.eclipse.emf.compare - Git at Google

 <?xml version='1.0' encoding='utf-8' ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
 	<head>
 		<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
 		<title>Architecture</title>
 		<link type="text/css" rel="stylesheet" href="/help/topic/org.eclipse.emf.compare.doc/doc/resources/bootstrap.css"/>
 		<link type="text/css" rel="stylesheet" href="/help/topic/org.eclipse.emf.compare.doc/doc/resources/custom.css"/>
 	</head>
 	<body>
 		<h1 id="Architecture">Architecture</h1>
 		<h2 id="Comparison_Process">Comparison Process</h2>
 		<p>
 			<div class="thumb middle">
 				<div class="thumbinner" style="width:802px;">
 					<a href="./../images/EMF_Compare_Process_Full.png" class="image">
 						<img class="thumbimage" width="800" align="middle" border="0" src="./../images/EMF_Compare_Process_Full.png"/>
 					</a>
 				</div>
 			</div>
 		</p>
 		<p>This is the overview of the comparison process as a whole. Each of the six phases of the comparison process of EMF Compare are briefly defined on the
 			<a href="./../overview/Overview.html" title="./../overview/Overview.html">Overview</a>, and a much more in-depth explanation will be given below, in our explanations of the
 			<a href="./Default%20Behavior%20and%20Extensibility.html" title="./Default%20Behavior%20and%20Extensibility.html">default behavior</a> of EMF Compare.
 		</p>
 		<h2 id="Project_Architecture">Project Architecture</h2>
 		<p>
 			<img align="middle" border="0" src="./../images/EMF_Compare_2_Architecture.png"/>
 		</p>
 		<p>EMF Compare is built on top of the Eclipse platform. We depend on the Eclipse Modeling Framework (EMF), the Eclipse Compare framework and, finally, Eclipse Team, the framework upon which the repository providers (EGit, CVS, Subversive...) are built.</p>
 		<p>The EMF Compare extensions target specific extensions of the modeling framework: UML, the Graphical Modeling Framework (and its own extensions, papyrus, ecoretools, ...).</p>
 		<p>Whilst we are built atop bricks that are tightly coupled with the eclipse platform, it should be noted that the core of EMF Compare can be run in a standalone application with no runtime dependencies towards Eclipse; as can EMF itself.</p>
 		<h2 id="The_Comparison_Model">The Comparison Model</h2>
 		<p>EMF Compare uses a single model, which root is a
 			<i>Comparison</i> object, to represent all of the information regarding the comparison: matched objects, matched resources, detected differences, links between these references, etc. The root
 			<i>Comparison</i> is created at the beginning of the Match process, and will undergo a set of successive refinings during the remainder of the Comparison: Diff, Equivalence, Dependencies... will all add their own information to the
 			<i>Comparison</i>.
 		</p>
 		<p>So, how exactly is represented all of the information the Comparison model can hold, and how to make sense of it all?</p>
 		<h3 id="Match">Match</h3>
 		<p>A
 			<i>Match</i> element is how we represent that the
 			<i>n</i> compared versions have elements that are basically the same. For example, if we are comparing two different versions
 			<i>v1</i> and
 			<i>v2</i> of a given model which look like:
 		</p>
 		<table border="1" cellpadding="5" cellspacing="0">
 			<tr>
 				<th align="center">Master</th>
 				<th align="center">Borrowables</th>
 			</tr>
 			<tr>
 				<td>
 					<img align="middle" border="0" src="./../images/v1.png"/>
 				</td>
 				<td>
 					<img align="middle" border="0" src="./../images/v2.png"/>
 				</td>
 			</tr>
 		</table>
 		<p>Comparing these two models, we'll have a Comparison model containing three matches:</p>
 		<ol>
 			<li>library &lt;-&gt; library</li>
 			<li>Book &lt;-&gt; Novel</li>
 			<li>title &lt;-&gt; title</li>
 		</ol>
 		<p>In other words, the comparison model contains an aggregate of the two or three compared models, in the form of
 			<i>Match</i> elements linking the elements of all versions together. Differences will then be detected on these
 			<i>Match</i> and added under them, thus allowing us to know both:
 		</p>
 		<ul>
 			<li>what the difference is (for example, "attribute name has been changed from
 				<i>Book</i> to
 				<i>Novel</i>"), and
 			</li>
 			<li>what the original elements were.</li>
 		</ul>
 		<h3 id="Diff">Diff</h3>
 		<p>
 			<i>Diff</i> elements are created during the differencing process in order to represent the actual modifications that can be detected within the source model(s). The
 			<i>Diff</i> concept itself is only there as the super-class of the three main kind of differences EMF Compare can detect in a model, namely
 			<i>ReferenceChange</i>,
 			<i>AttributeChange</i> and
 			<i>ResourceAttachmentChange</i>. We'll go back to these three sub-classes in a short while.
 		</p>
 		<p>Whatever their type, the differences share a number of common elements:</p>
 		<ul>
 			<li>a parent
 				<i>match</i>: differences are detected on a given
 				<i>Match</i>. Having a difference basically means that one of the elements paired through this
 				<i>Match</i> differs from its "reference" side (see
 				<i>source</i> description below).
 			</li>
 			<li>a
 				<i>source</i>: differences are detected on one side of their match. The source really only holds meaning in three-way comparisons, where a difference can be detected in either right or left. All differences detected through two-way comparisons have their source in the left side. This is because we always compare according to a "reference" side. During two-way comparisons, the reference side is the right: differences will always be detected on the left side as compared with the right side. During three-way comparisons though, differences can be detected on either left or right side as compared with their common ancestor; but never as compared to themselves (in other words, this is
 				<i>roughly</i> equivalent to two two-way comparisons, first the left as compared to the origin, then the right as compared to the origin).
 			</li>
 			<li>a current
 				<i>state</i>: all differences start off in their initial
 				<i>unresolved</i> state. The user can then choose to:
 				<ul>
 					<li>merge the difference (towards either right or left, applying or reverting the difference in the process), in which case the difference becomes
 						<i>merged</i>, or
 					</li>
 					<li>discard it, thus marking the change as
 						<i>discarded</i>. For example, if there is a conflicting edit of a textual attribute, the user can decide that neither right nor left are satisfying, and instead settle for a mix of the two.
 					</li>
 				</ul>
 			</li>
 			<li>a
 				<i>kind</i>: this is used by the engine to describe the type of difference it detected. Differences can be of four general types:
 				<ul>
 					<li>
 						<i>Add</i>: There are two distinct things that EMF Compare considers as an "addition". First, adding a new element within the values of a
 						<b>multi-valued feature</b> is undeniably an addition. Second, any change in a
 						<b>containment reference</b>, even if that reference is mono-valued, that represents a "new" element in the model is considered to be an addition. Note that this second case is an exception to the rule for
 						<i>change</i> differences outlined below.
 					</li>
 					<li>
 						<i>Delete</i>: this is used as the counterpart of
 						<i>add</i> differences, and it presents the same exception for
 						<b>mono-valued containment references</b>.
 					</li>
 					<li>
 						<i>Change</i>: any modification to a
 						<b>mono-valued feature</b> is considered as a
 						<i>change</i> difference by the engine. Take note that containment references are an exception to this rule: no
 						<i>change</i> will ever be detected on those.
 					</li>
 					<li>
 						<i>Move</i>: once again, two distinct things are represented as
 						<i>move</i> differences in the comparison model. First,
 						<b>reordering</b> the values of a multi-valued feature is considered as a series of MOVE: one difference for each moved value (EMF Compare computes the smallest number of differences needed between the two sides' values). Second, moving an object from
 						<b>one container to another</b> (changing the containing feature of the EObject) will be detected as a
 						<i>move</i>.
 					</li>
 				</ul>
 			</li>
 		</ul>
 		<p>In order to ensure that the model stays coherent through individual merge operations, we've also decided to link differences together through a number of associations and references. For example, there are times when one difference cannot be merged without first merging another, or some differences which are exactly equivalent to one another. In no specific order:</p>
 		<ul>
 			<li>
 				<i>dependency</i>: EMF Compare uses two oppposite references in order to track dependencies between differences. Namely,
 				<i>requires</i> and
 				<i>requiredBy</i> represent the two ends of this association. If the user has added a package
 				<i>P1</i>, then added a new Class
 				<i>C1</i> within this package, we will detect both differences. However the addition of
 				<i>C1</i> cannot be merged without first adding its container
 				<i>P1</i>. In such a case, the addition of
 				<i>C1</i>
 				<b>requires</b> the addition of
 				<i>P1</i>, and the later is
 				<b>requiredBy</b> the former.
 			</li>
 			<li>
 				<i>refinement</i>: this link is mainly used by extensions of EMF Compare in order to create high-level differences to hide the complexity of the comparison model. For example, this is used by the UML extension of EMF Compare to tell that the three differences "adding an association
 				<i>A1</i>", "adding a property
 				<i>P1</i> in association
 				<i>A1</i>" and "adding a property
 				<i>P2</i> in association
 				<i>A1</i>" is actually one single high-level difference, "adding an association
 				<i>A1</i>". This high-level difference is
 				<b>refinedBy</b> the others, which all
 				<b>refines</b> it.
 			</li>
 			<li>
 				<i>equivalence</i>: this association is used by the comparison engine in order to link together differences which are equivalent in terms of merging. For example, Ecore has a concept of
 				<b>eOpposite</b> references. Updating one of the two sides of an
 				<i>eOpposite</i> will automatically update the other. In such an event, EMF Compare will detect both sides as an individual difference. However, merging one of the two will trigger the update of the other side of the
 				<i>eOpposite</i> as well. In such cases, the two differences are set to be
 				<i>equivalent</i> to one another. Merging one difference part of an equivalence relationship will automatically mark all of the others as
 				<i>merged</i> (see
 				<i>state</i> above).
 			</li>
 			<li>
 				<i>implication</i>: implications are a special kind of "directed equivalence". A difference D1 that is linked as "implied by" another D2 means that merging D1 requires us to merge D1 instead. In other words, D2 will be automatically merged if we merge D1, but D1 will not be automatically merged if we merge D2. Implications are mostly used with UML models, where subsets and supersets may trigger such linked changes.
 			</li>
 			<li>
 				<i>conflict</i>: during three-way comparisons, we compare two versions of a given model with their common ancestor. We can thus detect changes that were made in either left or right side (see the description of
 				<i>source</i> above). However, there are cases when changes in the left conflict with changes in the right. For example, a class named "Book" in the origin model can have been renamed to "Novel" in the left model whereas it has been renamed to "Essay" in the right model. In such a case, the two differences will be marked as being in conflict with one another.
 			</li>
 		</ul>
 		<p>As mentionned above, there are only three kind of differences that we will detect through EMF Compare, which will be sufficient for all use cases.
 			<i>ReferenceChange</i> differences will be detected for every value of a reference for which we detect a change. Either the value was added, deleted, or moved (within the reference or between distinct references).
 			<i>AttributeChange</i> differences are the same, but for attributes instead of references. Lastly, the
 			<i>ResourceAttachmentChange</i> differences, though very much alike the ReferenceChanges we create for containment references, are specifically aimed at describing changes within the roots of one of the compared resources.
 		</p>
 		<h3 id="Conflict">Conflict</h3>
 		<p>
 			<b>Conflict</b> will only be detected during three-way comparisons. There can only be "conflicts" when we are comparing two different versions of a same model along with their common ancestor. In other words, we need to able to compare two versions of a common element with a "reference" version of that element.
 		</p>
 		<p>There are many different kinds of conflicts; to name a few:</p>
 		<ul>
 			<li>changing an element on one side (in any way, for example, renaming it) whilst that element has been removed from the other side</li>
 			<li>changing the same attribute of an element on both sides, to different values (for example, renaming "Book" to "Novel" on the left while be renamed "Book" to "Essay" on the right)</li>
 			<li>creating a new reference to an element on one side whilst it had been deleted from the other side</li>
 		</ul>
 		<p>Conflicts can be of two kinds. We call
 			<i>PSEUDO</i> conflict a conflict where the two sides of a comparison have changed as compared to their common ancestor, but where the two sides are actually now equal. In other words, the end result is that the left is now equal to the right, even though they are both different from their ancestor. This is the opposite of
 			<i>REAL</i> conflict where the value on all three sides is different. In terms of merging, pseudo conflicts do not need any particular action, whilst real conflicts actually need resolution.
 		</p>
 		<p>There can be more than two differences conflicting with each other. For example, the deletion of an element from one side will most likely conflict with a number of differences from the other side.</p>
 		<h3 id="Equivalence">Equivalence</h3>
 		<p>EMF Compare uses
 			<b>Equivalence</b> elements in order to link together a number of differences which can ultimately be considered to be the same. For example, ecore's
 			<i>eOpposite</i> references will be maintained in sync with one another. As such, modifying one of the two references will automatically update the second one accordingly. The manual modification and the automatic update are two distinct modifications of the model, resulting in two differences detected. However, merging any of these two differences will automatically merge the other one. Therefore both are marked as being equivalent to each other.
 		</p>
 		<p>There can be more than two differences equivalent with each other; in which case all will be added to a single
 			<i>Equivalence</i> object, representing their relations.
 		</p>
 	</body>
 </html>
	<?xml version='1.0' encoding='utf-8' ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
	<title>Architecture</title>
	<link type="text/css" rel="stylesheet" href="/help/topic/org.eclipse.emf.compare.doc/doc/resources/bootstrap.css"/>
	<link type="text/css" rel="stylesheet" href="/help/topic/org.eclipse.emf.compare.doc/doc/resources/custom.css"/>
	</head>
	<body>
	<h1 id="Architecture">Architecture</h1>
	<h2 id="Comparison_Process">Comparison Process</h2>
	<p>
	<div class="thumb middle">
	<div class="thumbinner" style="width:802px;">
	<a href="./../images/EMF_Compare_Process_Full.png" class="image">
	<img class="thumbimage" width="800" align="middle" border="0" src="./../images/EMF_Compare_Process_Full.png"/>
	</a>
	</div>
	</div>
	</p>
	<p>This is the overview of the comparison process as a whole. Each of the six phases of the comparison process of EMF Compare are briefly defined on the
	<a href="./../overview/Overview.html" title="./../overview/Overview.html">Overview</a>, and a much more in-depth explanation will be given below, in our explanations of the
	<a href="./Default%20Behavior%20and%20Extensibility.html" title="./Default%20Behavior%20and%20Extensibility.html">default behavior</a> of EMF Compare.
	</p>
	<h2 id="Project_Architecture">Project Architecture</h2>
	<p>
	<img align="middle" border="0" src="./../images/EMF_Compare_2_Architecture.png"/>
	</p>
	<p>EMF Compare is built on top of the Eclipse platform. We depend on the Eclipse Modeling Framework (EMF), the Eclipse Compare framework and, finally, Eclipse Team, the framework upon which the repository providers (EGit, CVS, Subversive...) are built.</p>
	<p>The EMF Compare extensions target specific extensions of the modeling framework: UML, the Graphical Modeling Framework (and its own extensions, papyrus, ecoretools, ...).</p>
	<p>Whilst we are built atop bricks that are tightly coupled with the eclipse platform, it should be noted that the core of EMF Compare can be run in a standalone application with no runtime dependencies towards Eclipse; as can EMF itself.</p>
	<h2 id="The_Comparison_Model">The Comparison Model</h2>
	<p>EMF Compare uses a single model, which root is a
	<i>Comparison</i> object, to represent all of the information regarding the comparison: matched objects, matched resources, detected differences, links between these references, etc. The root
	<i>Comparison</i> is created at the beginning of the Match process, and will undergo a set of successive refinings during the remainder of the Comparison: Diff, Equivalence, Dependencies... will all add their own information to the
	<i>Comparison</i>.
	</p>
	<p>So, how exactly is represented all of the information the Comparison model can hold, and how to make sense of it all?</p>
	<h3 id="Match">Match</h3>
	<p>A
	<i>Match</i> element is how we represent that the
	<i>n</i> compared versions have elements that are basically the same. For example, if we are comparing two different versions
	<i>v1</i> and
	<i>v2</i> of a given model which look like:
	</p>
	<table border="1" cellpadding="5" cellspacing="0">
	<tr>
	<th align="center">Master</th>
	<th align="center">Borrowables</th>
	</tr>
	<tr>
	<td>
	<img align="middle" border="0" src="./../images/v1.png"/>
	</td>
	<td>
	<img align="middle" border="0" src="./../images/v2.png"/>
	</td>
	</tr>
	</table>
	<p>Comparing these two models, we'll have a Comparison model containing three matches:</p>
	<ol>
	<li>library <-> library</li>
	<li>Book <-> Novel</li>
	<li>title <-> title</li>
	</ol>
	<p>In other words, the comparison model contains an aggregate of the two or three compared models, in the form of
	<i>Match</i> elements linking the elements of all versions together. Differences will then be detected on these
	<i>Match</i> and added under them, thus allowing us to know both:
	</p>
	<ul>
	<li>what the difference is (for example, "attribute name has been changed from
	<i>Book</i> to
	<i>Novel</i>"), and
	</li>
	<li>what the original elements were.</li>
	</ul>
	<h3 id="Diff">Diff</h3>
	<p>
	<i>Diff</i> elements are created during the differencing process in order to represent the actual modifications that can be detected within the source model(s). The
	<i>Diff</i> concept itself is only there as the super-class of the three main kind of differences EMF Compare can detect in a model, namely
	<i>ReferenceChange</i>,
	<i>AttributeChange</i> and
	<i>ResourceAttachmentChange</i>. We'll go back to these three sub-classes in a short while.
	</p>
	<p>Whatever their type, the differences share a number of common elements:</p>
	<ul>
	<li>a parent
	<i>match</i>: differences are detected on a given
	<i>Match</i>. Having a difference basically means that one of the elements paired through this
	<i>Match</i> differs from its "reference" side (see
	<i>source</i> description below).
	</li>
	<li>a
	<i>source</i>: differences are detected on one side of their match. The source really only holds meaning in three-way comparisons, where a difference can be detected in either right or left. All differences detected through two-way comparisons have their source in the left side. This is because we always compare according to a "reference" side. During two-way comparisons, the reference side is the right: differences will always be detected on the left side as compared with the right side. During three-way comparisons though, differences can be detected on either left or right side as compared with their common ancestor; but never as compared to themselves (in other words, this is
	<i>roughly</i> equivalent to two two-way comparisons, first the left as compared to the origin, then the right as compared to the origin).
	</li>
	<li>a current
	<i>state</i>: all differences start off in their initial
	<i>unresolved</i> state. The user can then choose to:
	<ul>
	<li>merge the difference (towards either right or left, applying or reverting the difference in the process), in which case the difference becomes
	<i>merged</i>, or
	</li>
	<li>discard it, thus marking the change as
	<i>discarded</i>. For example, if there is a conflicting edit of a textual attribute, the user can decide that neither right nor left are satisfying, and instead settle for a mix of the two.
	</li>
	</ul>
	</li>
	<li>a
	<i>kind</i>: this is used by the engine to describe the type of difference it detected. Differences can be of four general types:
	<ul>
	<li>
	<i>Add</i>: There are two distinct things that EMF Compare considers as an "addition". First, adding a new element within the values of a
	<b>multi-valued feature</b> is undeniably an addition. Second, any change in a
	<b>containment reference</b>, even if that reference is mono-valued, that represents a "new" element in the model is considered to be an addition. Note that this second case is an exception to the rule for
	<i>change</i> differences outlined below.
	</li>
	<li>
	<i>Delete</i>: this is used as the counterpart of
	<i>add</i> differences, and it presents the same exception for
	<b>mono-valued containment references</b>.
	</li>
	<li>
	<i>Change</i>: any modification to a
	<b>mono-valued feature</b> is considered as a
	<i>change</i> difference by the engine. Take note that containment references are an exception to this rule: no
	<i>change</i> will ever be detected on those.
	</li>
	<li>
	<i>Move</i>: once again, two distinct things are represented as
	<i>move</i> differences in the comparison model. First,
	<b>reordering</b> the values of a multi-valued feature is considered as a series of MOVE: one difference for each moved value (EMF Compare computes the smallest number of differences needed between the two sides' values). Second, moving an object from
	<b>one container to another</b> (changing the containing feature of the EObject) will be detected as a
	<i>move</i>.
	</li>
	</ul>
	</li>
	</ul>
	<p>In order to ensure that the model stays coherent through individual merge operations, we've also decided to link differences together through a number of associations and references. For example, there are times when one difference cannot be merged without first merging another, or some differences which are exactly equivalent to one another. In no specific order:</p>
	<ul>
	<li>
	<i>dependency</i>: EMF Compare uses two oppposite references in order to track dependencies between differences. Namely,
	<i>requires</i> and
	<i>requiredBy</i> represent the two ends of this association. If the user has added a package
	<i>P1</i>, then added a new Class
	<i>C1</i> within this package, we will detect both differences. However the addition of
	<i>C1</i> cannot be merged without first adding its container
	<i>P1</i>. In such a case, the addition of
	<i>C1</i>
	<b>requires</b> the addition of
	<i>P1</i>, and the later is
	<b>requiredBy</b> the former.
	</li>
	<li>
	<i>refinement</i>: this link is mainly used by extensions of EMF Compare in order to create high-level differences to hide the complexity of the comparison model. For example, this is used by the UML extension of EMF Compare to tell that the three differences "adding an association
	<i>A1</i>", "adding a property
	<i>P1</i> in association
	<i>A1</i>" and "adding a property
	<i>P2</i> in association
	<i>A1</i>" is actually one single high-level difference, "adding an association
	<i>A1</i>". This high-level difference is
	<b>refinedBy</b> the others, which all
	<b>refines</b> it.
	</li>
	<li>
	<i>equivalence</i>: this association is used by the comparison engine in order to link together differences which are equivalent in terms of merging. For example, Ecore has a concept of
	<b>eOpposite</b> references. Updating one of the two sides of an
	<i>eOpposite</i> will automatically update the other. In such an event, EMF Compare will detect both sides as an individual difference. However, merging one of the two will trigger the update of the other side of the
	<i>eOpposite</i> as well. In such cases, the two differences are set to be
	<i>equivalent</i> to one another. Merging one difference part of an equivalence relationship will automatically mark all of the others as
	<i>merged</i> (see
	<i>state</i> above).
	</li>
	<li>
	<i>implication</i>: implications are a special kind of "directed equivalence". A difference D1 that is linked as "implied by" another D2 means that merging D1 requires us to merge D1 instead. In other words, D2 will be automatically merged if we merge D1, but D1 will not be automatically merged if we merge D2. Implications are mostly used with UML models, where subsets and supersets may trigger such linked changes.
	</li>
	<li>
	<i>conflict</i>: during three-way comparisons, we compare two versions of a given model with their common ancestor. We can thus detect changes that were made in either left or right side (see the description of
	<i>source</i> above). However, there are cases when changes in the left conflict with changes in the right. For example, a class named "Book" in the origin model can have been renamed to "Novel" in the left model whereas it has been renamed to "Essay" in the right model. In such a case, the two differences will be marked as being in conflict with one another.
	</li>
	</ul>
	<p>As mentionned above, there are only three kind of differences that we will detect through EMF Compare, which will be sufficient for all use cases.
	<i>ReferenceChange</i> differences will be detected for every value of a reference for which we detect a change. Either the value was added, deleted, or moved (within the reference or between distinct references).
	<i>AttributeChange</i> differences are the same, but for attributes instead of references. Lastly, the
	<i>ResourceAttachmentChange</i> differences, though very much alike the ReferenceChanges we create for containment references, are specifically aimed at describing changes within the roots of one of the compared resources.
	</p>
	<h3 id="Conflict">Conflict</h3>
	<p>
	<b>Conflict</b> will only be detected during three-way comparisons. There can only be "conflicts" when we are comparing two different versions of a same model along with their common ancestor. In other words, we need to able to compare two versions of a common element with a "reference" version of that element.
	</p>
	<p>There are many different kinds of conflicts; to name a few:</p>
	<ul>
	<li>changing an element on one side (in any way, for example, renaming it) whilst that element has been removed from the other side</li>
	<li>changing the same attribute of an element on both sides, to different values (for example, renaming "Book" to "Novel" on the left while be renamed "Book" to "Essay" on the right)</li>
	<li>creating a new reference to an element on one side whilst it had been deleted from the other side</li>
	</ul>
	<p>Conflicts can be of two kinds. We call
	<i>PSEUDO</i> conflict a conflict where the two sides of a comparison have changed as compared to their common ancestor, but where the two sides are actually now equal. In other words, the end result is that the left is now equal to the right, even though they are both different from their ancestor. This is the opposite of
	<i>REAL</i> conflict where the value on all three sides is different. In terms of merging, pseudo conflicts do not need any particular action, whilst real conflicts actually need resolution.
	</p>
	<p>There can be more than two differences conflicting with each other. For example, the deletion of an element from one side will most likely conflict with a number of differences from the other side.</p>
	<h3 id="Equivalence">Equivalence</h3>
	<p>EMF Compare uses
	<b>Equivalence</b> elements in order to link together a number of differences which can ultimately be considered to be the same. For example, ecore's
	<i>eOpposite</i> references will be maintained in sync with one another. As such, modifying one of the two references will automatically update the second one accordingly. The manual modification and the automatic update are two distinct modifications of the model, resulting in two differences detected. However, merging any of these two differences will automatically merge the other one. Therefore both are marked as being equivalent to each other.
	</p>
	<p>There can be more than two differences equivalent with each other; in which case all will be added to a single
	<i>Equivalence</i> object, representing their relations.
	</p>
	</body>
	</html>