In general, comparison of resources is divided into two different types. One is to compare two resources with each other. This is called a two-way compare. A two-way compare can only reveal differences between resources, but can not recognize in which resource a change was performed. A two-way compare in Eclipse is obtained by selecting two resources and then choosing Compare With->Each Other from the context menu. Other two-way comparisons supported by Eclipse are Compare With->Revision and Compare With->Local History .

A more comfortable compare is the so called three-way compare. In addition it has an ancestor resource from which is known that this is the unchanged resource. In this way it can be determined which change was performed in which resource. Such compare editors are opened for instance for synchronizing resources with CVS repositories which always maintain a third ancestor resource by using Compare With->Latest from Head and Compare With->Another Branch or Version .

The compare editor is divided into an upper and a lower part. The upper part shows structural changes in a difference tree. The lower part presents two text editors located next to each other. Changes are highlighted in colored lines or rectangles on both sides. Those belonging to one change are connected with a line. For two-way comparisons the changes are always grey-colored. In three-way comparisons outgoing (local) changes are grey-colored, incoming (remote) changes blue-colored, and changes on both sides which are conflicting are red-colored.

A resource compare can be used to view changes for two resources. In addition it provides the possibility to apply single changes to local models. Therefor the compare editor provides a toolbar, located between the upper and the lower part, with actions which can be used to apply changes: Copy All from Left to Right , Copy All Non-Conflicting Changes from Right to Left , Copy Current Change from Left to Right , Copy Current Change from Right to Left , Select Next Change , Select Previous Change . You can step through the changes and apply them if the specific buttons are enabled. As stated above refer to the Eclipse Workbench User Guide for detailed information on this.

In general the Eclipse text compare editor is opened for any resource after calling the actions described in the previous section. For pure::variants models the special pure::variants Model Compare Editor is opened. This makes it easier to recognize changes in pure::variants models. Typical changes are for example Element Added, Attribute Removed, Relation Target Changed .

The upper part of the editor, i.e. the structure view, displays a patch tree with a maximum depth of three. Here all patches are grouped by their affiliation to elements. Thus Element Added and Element Removed are shown as top level patches. All other patches are grouped into categories below their elements they belong to. Following categories exist: General , Attributes , Relations , Restrictions , Constraints and Misc . The names of the categories indicate which patches are grouped together. Below the category Misc only patches are shown that are usually not displayed in the models tree viewer. As in the Eclipse text compare you can step through the patches with the specific buttons. Each step down always expands a model patch if possible and steps into it. The labels for the patch consist of a brief patch description, the label of the patched model item and a concrete visualization of the old and the new value if it makes sense. Here is an example: Attribute Constant Changed: attrname = 'newValue' <- oldValue. In this attribute patch's label a new value is not additionally appended, because it is part of the attributes (new) label "attrname = 'newValue' ".

The lower part of the model compare editor is realized using the usual model tree viewers also used in the model editors. They are always expanded to ensure that all patches are visible. As in the text compare editors, patches are visualized by colorized highlighted rectangle areas or lines using the same colors. In opposite to the text compare they are only shown if the patch is selected in the upper structure view. For two-way comparisons it is ambiguous which model was changed. Because of this an additional button is provided in the toolbar which allows to exchange two models currently opened in the model compare editor. This leads from a remove-patch into an add-patch, and for a change the new and the old value are exchanged.

The model compare editor compares two model resources on the model abstraction layer. Hence textual differences may exist between two models where the model compare editor shows no changes. Thus conflicts that would be shown in a textual compare are not shown in the model compare editor. This allows the user to apply all patches in one direction as desired and then to override into the other direction.

In three-way comparisons it may occur that an incoming and an outgoing patch conflict with each other. In general the model compare editor distinguishes between fatal conflicting patches and warning conflicts. In the tree viewer conflicts are red-colored. A fatal conflict is for example an element change on one side, while this element was deleted on the other side. One of these patches is strictly not executable. Usually warning conflicts can be merged, but it is not sure that the resulting model is patched correctly. Typical misbehaviour could be that some items are order inverted. To view which patch conflicts with which other path just move the mouse above one of the conflicting patches in the upper structure view. This and the conflicting patch then change their background color either to red for fatal conflicts or yellow for conflict warnings.

In general a sophisticated algorithm tries to determine conflicts between two patches. These results are very safe hints, but 100% safety is not given. For a conflicting or non-conflicting patch it may occur that it can not be executed. Conflict warning patches may be executed without problems and lead to a correct model change. In general the user can try to execute any patch. If there are problems then the user is informed about that. If there are problems applying a non-conflicting patch, the editor should be closed without saving and reopened. Then another order of applying patches can solve this problem. The actions Apply All Changes ... do only apply incoming and non-conflicting changes. Other patches must be selected and patched separately.

Figure 6.30, “Model Compare Editor” shows an example how a model compare editor could look like for a model that is synchronized with CVS. The upper part shows the structure view with all patches visible and expanded representing the model differences. A CVS synchronize is always a three-way compare. There are incoming changes (made in the remote CVS model) and outgoing (local) changes. As to see in the figure the incoming changes have a blue left arrow as icon, while outgoing changes have a grey right-arrow as icon. Added or removed items have a plus or a minus composed to the icon. Conflicting changes are marked with a red arrow in both directions displayed only at the element as the patches top level change. In this example a conflict arises at the element conflicting. In CVS its unique name changed and a relation was added while this element was deleted locally. Two patches show a red background because the mouse hovered above one of these patches which is not visible in the figure. Note that the tree viewers in the lower part show only the patches which are selected above. The colors correspond to the patch direction.

Figure 6.30. Model Compare Editor