Conflicts must preserve both versions

What it is

When a conflict occurs, the system must keep both versions alive and let a human decide what happens next — the floor of non-destructive conflict resolution. Its job is not to rule on who was right, only to guarantee that before any ruling is made, neither party's work disappears as a side effect of the collision. The interface may be a side-by-side comparison, an either/or choice, or manual fusion — but whatever is chosen, the un-adopted version must remain recoverable. This complements automatic merging rather than competing with it: merging handles concurrent edits that do not interfere; version preservation handles the collisions that truly overlap and need a human.

Why it happens

Resolution authority belongs to people, and people need time and information: the other party is not present, the intent behind both edits is not fully visible, and someone with more context may need to come back. Preserving both versions effectively decouples conflict resolution from the moment of saving — no verdict is due at save time; the conflict is frozen into an object that can be dealt with later. Two consequences follow. Decision quality: a considered trade-off made while comparing both versions beats an arbitrary millisecond ruling by the system. And psychological safety: contributions stop vanishing due to an event unrelated to their quality ("someone else edited the same spot"), which is what makes people willing to invest directly in the shared space at all. Technically this requires separating storage of the conflicted state from its presentation: the content layer holds both versions; only then can the interface layer decide how to display the choice.

Where it stops holding

Preservation is not indefinite stockpiling. A pair of conflicting versions is a pending state, not a third kind of document body; conflicts that nobody processes accumulate into "conflict debt" that daunts users until the whole region gets avoided. Retention horizon and presentation prominence should scale with content importance: conflicts on the mainline of a codebase must block and be resolved immediately; conflicts in a scratch area can be gently flagged and cleaned up on a deadline. And preserving both versions secures the content layer, not understanding — why the conflict happened and what the other side intended is the job of context; the two mechanisms only work as a pair.

Applying it

• In the conflict screen, alongside "keep mine / keep theirs / merge manually," always offer "decide later," with a re-entry point that can be found again (a conflict list, a to-do marker).
• Route the losing version into version history or a conflict archive with clear provenance and timestamps — never discard it.
• When conflict volume is high, provide a region-grouped conflict list so resolution can proceed in batches instead of intimidating the user all at once.
• Verification: walk every conflict-producing path in the product and check whether the un-adopted version is still recoverable 30 days later; if no recovery entry point exists, it fails.

Related

• Same group: V3.02.1 Silent overwrite is the most serious collaboration failure · V3.02.3 Resolving a conflict requires enough context
• Nearby: V3.01 Concurrent Editing · V3.03 Version History
• Search terms: non-destructive conflict resolution · conflict preservation · three-way merge · version retention