Tensions in Practice: Parallel editing in tension with integration effort¶
Versioned layout · merge-difficult artifact
Two people need to change the same layout file. If B waits for A’s completed version, their changes follow one evolving history. If both start from the original, work can proceed together but produces two successors that need reconciliation. Version identifiers preserve those states; they do not tell a merge tool which overlapping design choices should survive.
Let contributors work together
Avoid making independent contributors wait for a single editing turn.
Keep one coherent successor
Produce an integrated artifact whose combined changes have been checked.
Why these aims pull against each other
Parallel branches defer coordination to integration. Serial turns avoid that particular divergence by moving the waiting before the second edit.
Choose an arrangement to see what changes and what remains difficult.
Qualitative paths and conditions, not measured costs, timings or performance guarantees.
What this choice protects
What it costs
When it fits
Compare the arrangements
Pass one file
A edits V0, then B edits A’s completed V1, retaining each named state.
- What it protects
- The second editor works from the first editor’s actual result, so there is no parallel-successor merge.
- What it costs
- B waits; a long editing turn becomes a collaboration bottleneck.
- When it fits
- Fits tightly coupled changes, limited merge tooling, or an artifact whose manual integration would cost more than waiting.
Illustration note: The illustration assumes contributors honor the turn and still review changes. Serial editing does not prevent a later editor from introducing a mistake.
Branch then reconcile
A and B independently edit V0 and retain both successors for type-specific or manual reconciliation.
- What it protects
- Both contributors can make progress without waiting for the other’s editing turn.
- What it costs
- Conflicting layout choices require inspection and possible rework; recording both versions does not settle the conflict.
- When it fits
- Fits useful independent work and an explicit integration owner with the time and tools to reconcile the artifact.
Illustration note: The chosen artifact is merge-difficult. This is not a claim that every binary format or document product lacks useful merge support.
What this illustration does—and does not—establish
Versioning: Merging Non-Text Artifacts Is Hard supplies the artifact-sensitive merge cost. The named layout successors expose exactly where divergence is introduced.
- The graph shows lineage and editing order, not elapsed-time estimates.
- Version retention is not a backup strategy or a guarantee that a merged result is correct.
Source entries
Versioning
Versioning: Merging Non-Text Artifacts Is Hard supplies the conflict examined here.
Merging Non-Text Artifacts Is Hard
- T2: Merging Non-Text Artifacts Is Hard. Three-way text merge handles source code well; binary files (Word, PowerPoint), structured schemas, and some data formats merge poorly. A common failure is teams serializing changes on merge-difficult artifacts (only one person edits at a time), causing collaboration bottlenecks and conflicts requiring manual resolution per-file-type.