frontend-patterns/research/bench/infospaces/obsidian-conflicts-01/artifacts/generated/candidates.md

P01 Conflict File Preservation

Definition

A mechanism where, upon detecting conflicting changes to a shared resource, a system creates a separate, new file containing one version of the conflicting content, while the original file retains the other version. This defers the resolution of the conflict to the user.

Candidate Identity

P01, Family: Conflict Resolution, Scale: File, Status: Draft, Maturity: Hypothesis, Evidence_kind: Primary

Context

A user is collaborating on or synchronizing a file across multiple devices or instances. Changes are made to the same file independently on different systems.

Problem

When conflicting changes are made to a shared file, the system needs a strategy to handle these discrepancies without data loss and without forcing an immediate, potentially incorrect, automatic merge.

Forces

1. Data Preservation: The need to ensure that no user-made changes are lost, even if they conflict. This pushes towards preserving all versions.
2. System Simplicity vs. User Control: An automatic merge is simpler for the system but might produce an incorrect result. Preserving both versions requires user intervention but offers full control.
3. Synchronization Integrity: The desire to keep the primary synchronized file consistent with one authoritative source (e.g., the remote version).

Solution

When a conflict is detected, the system creates a new "conflict file" containing the local, conflicting changes. The original file is updated with the remote version of the content.

Dynamics

1. A file A exists on a local system and a remote system.
2. Changes are made to A locally, resulting in A_local.
3. Concurrently, changes are made to A remotely, resulting in A_remote.
4. When synchronization occurs, the system detects that A_local and A_remote differ.
5. Instead of attempting an automatic merge, the system creates a new file (e.g., A_conflict) containing the content of A_local.
6. The original file A is updated with the content of A_remote.
7. The user is left with two files: A (remote version) and A_conflict (local version), and must manually reconcile them.

Resulting Context

The user has two distinct files representing the conflicting versions. The primary file reflects the remote state, and a new file holds the local, conflicting changes. The conflict is not resolved by the system but is presented for user resolution.

Consequences

• Pros: Guarantees no data loss from either conflicting version. Provides the user with full control over conflict resolution. Keeps the main file consistent with the remote source.
• Cons: Requires manual user intervention to resolve conflicts. Can lead to file clutter if conflicts are frequent and not resolved promptly. The user must understand which file contains which version.

Failure Modes

• The conflict file is not clearly named or located, making it difficult for the user to find and understand.
• The system fails to detect a conflict and overwrites one version without creating a conflict file.
• The user is not notified of the conflict, leading to unnoticed divergence.

Source Evidence

• C01: "Obsidian Sync can be configured to create a separate conflict file instead of automatically merging conflicting changes." (SRC-0006, Passage A)
• C02: "When a conflict file is created, the original file retains the remote version of the content." (SRC-0006, Passage B)

Counterevidence

None.

Review Notes

This pattern explicitly separates the act of preserving conflicting versions from the act of resolving them, pushing the latter to the user.

Known uses

Known uses: unknown Recurrence: unknown

{"candidates": [{"id": "P01", "known_uses": [], "recurrence": "unknown"}]}