Three-to-two Merge Use Cases

Three to Two Merge Use Cases

This section describes common use cases where converting a three-way merge result into a two-way simplified representation is the preferred approach.

Use Case 1: Editorial Round-Trip Through Document Editors

When a document needs to be reviewed and approved in a document editing tool (such as oXygen XML Author or Adobe InDesign), the three-way DeltaV2 format is too complex for the editor to display natively. The Three-to-Two Merge produces a simplified result that the editor can render using its built-in change-tracking UI.

Recommended result type: ALL_CHANGES with TwoWayResultFormat=OXYGEN_TRACK_CHANGES

Use Case 2: Reviewer-Friendly Change Presentation

When presenting merged changes to a non-technical reviewer, the simplified two-way format is easier to understand than the full three-way DeltaV2. Non-conflicting changes that were made by one editor are shown as accepted; only genuine conflicts appear as pending tracked changes.

Recommended result type: CONFLICTING_CHANGES

Use Case 3: Auto-Resolution of Non-Conflicting Changes

In automated publishing workflows, non-conflicting changes (where one author made a change and the other did not) can be auto-accepted, leaving only genuine conflicts for human review.

Recommended result type: RULE_PROCESSED_DELTAV2 (concurrent) or CONFLICTING_CHANGES (concurrent3)

Use Case 4: Remote Branch Integration

In a version-control-style workflow, the 'their changes' mode presents changes from a remote branch while auto-resolving local changes that do not conflict. This mirrors the familiar git merge mental model.

Recommended result type: THEIR_CHANGES

Choosing the Right Result Type

Scenario

Recommended ResultType

Show all tracked changes for review

ALL_CHANGES

Show only conflicts; accept everything else

CONFLICTING_CHANGES

Integrate remote branch changes

THEIR_CHANGES

oXygen track-changes round-trip

OXYGEN_TRACK_CHANGES

Programmatic auto-resolution

RULE_PROCESSED_DELTAV2