The Merge 6.0 release has introduced a new merge type called Sequential Merge. The merge product now has three different merge types: ConcurrentMerge, SequentialMerge and ThreeWayMerge.
|Result Type||Concurrent Merge||Three Way Merge||Sequential Merge|
|Rule Processed DeltaV2||✔||✔|
|Simplified Rule Processed DeltaV2||✔||✔|
|Two Way Result||✔|
|Rule Processed Two Way Result||✔|
|Two Way Oxygen Track Changes||✔|
|Three Way Oxygen Track Changes||✔|
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||✔||✔||✔✔✔||✔✔|
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 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.
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.
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 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.
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.
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 a plugin or '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. A web-based resolving system ('XMLFlow') is also under development. Both of these systems are designed to handle nested change.
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.
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.