Merge Result Formats and Types

Introduction

As a user of XML Megre you will need to understand the different types of results and when to use them. This page summarizes the result types and their differences and offers advice as to which may be appropriate for different user requirements and use-cases.

Result Formats and Result types

The following table summarizes the result format differences and offers advice as to which may be appropriate for different user requirements and use-cases.

	deltaV2	rule processed deltaV2	simplified delta	two way results
Number of inputs	3+	3+	3+	3
Extract all inputs	✔		✔
Supports nested change	✔	✔
Use with editor accept/reject				✔
Use with DeltaXML Oxygen plugin	✔	✔
Suitability for automated processing	✔✔✔	✔✔✔	✔✔	✔✔✔
Suitability for manual resolution	✔	✔	✔✔✔	✔✔

Considerations

Number of inputs

The ConcurrentMerge class is designed as n-way merge system and therefore supports an unlimited number of input XML files or trees. The use of a common ancestor to guide the alignment process in addition to two versions or branches being merged means that a minimum of three XML inputs are required.

The ThreeWayMerge has all of the capabilities of the n-way ConcurrentMerge class but provides some additional capabilities suited to the three way use cases such as the ability to represent and simplify the merge results using a two-way representation.

The SequentialMerge class is also designed as a n-way merge system and therefore supports an unlimited number of input XML files or trees. SequentialMerge requires a minimum of three inputs where each version is derived from the previous version.

Extract all inputs

A complete representation of each input file means that there is no loss of information in the merged file, i.e. any one of the input files could be extracted as an XML tree. This is a general property of the merge system.. However some result formats and representations provide simplifications or processing that restrict this capability. In particular:

The rule processing system used with deltaV2 and simplified result formats automatically process changes such as adds and deletes. After these changes are processed the full details of these changes cannot be reversed and therefore all of the inputs cannot be extracted.
The three-to-way way result simplification process by design removes information associated the the ancestor input in order to emphasise changes between the branches being merged.

Supports nested change

The merge system supports generating optimal results which avoid repetition of content from the inputs. When three or more inputs are involved such a representation involves nested change. The simplified result format and the three-to-two way result simplification process are designed to remove the need for a nested change representation. This allows the results to be used with simpler user interfaces and editing processes, but with the potential loss of some detail in the result. The support for nested change is closely related to the types of user-interface available with the various result types.

Use with editor accept/reject

XML editors often provide accept/reject style user interfaces that can be used to process track-change recording and in some cases comparison results. This type of user interface supports add and delete operations and is unsuited to general n-way merge result processing. However the three-to-two way processing options available with the ThreeWayMerge class were designed to support this type of interface with the compromise that in some cases a little information, typically related to the ancestor input, cannot be presented to the user.

Use with DeltaXML Oxygen plugin

A user-interface specific to n-way merge operations has been developed in order to demonstrate the possibilities that an n-way algorithm and interface can provide. DeltaXML has developed an add-on for the Oxygen editor for content used with the editor's author mode. This allows the user to deal with n-way conflicts as well as non-conflicting changes such as additions and deletions. This system is also designed to handle nested change.

Suitability for automated processing

The n-way form of the deltaV2 result format was designed for ease of XSLT processing and conversion into other types of result. Using this result representation, it is easy to make processing decisions at various points in the XML tree as each element has information about any descendant change using the deltaV2 attribute. The format is also minimal so that information is not repeated unnecessarily.

Suitability for manual resolution

The deltaV2 format has information throughout the XML tree hierarchy that becomes laborious to process manually, for example when a user wishes to resolve merge conflicts or changes using an XML editor. A major driver in the design of the simplified delta format was to make manual processing of merge results easier. The simplified result can also be processed automatically using XSLT or technologies, however the change representation is not as rich as deltaV2.

Table of Merge Types and Result Types

Result Type	See page(s)	Notes
All Merge Types
DeltaV2	DeltaV2 Reference, The DeltaV2 Merge Format, Overlapping Hierarchies in DeltaV2 and DELTAV2	Also used by XML Compare. Some parts are particularly significant in XML Merge.
Analyzed DeltaV2	Concurrent Merge Analysis , Sequential Merge Analysis, ANALYZED_DELTAV2	Additional delta attributes are used to identify the types of changes.
Simplified DeltaV2	The Simplified Merge Format, SIMPLIFIED_DELTAV2	Created to make manual resolution of changes easier, although small changes nested within larger changes can be harder to see and there is some change information loss.
Concurrent & Three Way Merge only
Simplified Rule Processed DeltaV2	SIMPLIFIED_RULE_PROCESSED_DELTAV2
Rule Processed DeltaV2	Rule Based Processing, RULE_PROCESSED_DELTAV2	A result which is analysed and then has various processing rules applied to process simple changes leaving interesting conflicts for interactive display and/or resolution.
Three Way Merge only
Two Way Result	Three To Two Merge, TWO_WAY_RESULT, ALL_CHANGES, CONFLICTING_CHANGES, THEIR_CHANGES	A three to two way merge result. This form of result presents a three-way merge as a two-way resultthat may be more familiar to users of systemssuch as accept/reject. In some cases information from the ancestor version is lost. Rather than being from the perspective of the ancestor version, the concept of add and delete is seen from the perspective of one of the versions, the 'local' version. This is supplied as the second argument of the merge methods or the first version supplied using addVersion methods. The third merge argument, or second supplied using addVersion, is seen as the other branch which is being merged from and in many version control systems is referred to as the 'remote branch', the 'other branch' or 'their' branch.
Rule Processed Two Way Result	RULE_PROCESSED_TWO_WAY_RESULT	A three to two way merge result with rule processing. The processing to convert a raw three way merge result is the same as that described for TWO_WAY_RESULT. Similarly the rule processing that is applied is the same process used with the RULE_PROCESSED_TWO_WAY_RESULT.
Two Way Oxygen Track Changes	TWO_WAY_RESULT and TwoWayResultFormat.OXYGEN_TRACK_CHANGES	A three to two way merge result with Oxygen Author-mode track changes processing instructions.
Three Way Oxygen Track Changes	THREE_WAY_OXYGEN_TRACK_CHANGES	A result format with Oxygen Author-mode track changes processing instructions. The result will contain change author information derived from the input version identifiers used in the merge methods or setAncestor/addVersion methods. The result is a symmetrical representation of the changes from the perspective of the ancestor version.