Conflicts & versioning

cnfgr is built so that syncing never silently overwrites work you’re in the middle of. Most concurrent edits merge cleanly thanks to the CRDT sync model; the cases that genuinely conflict are surfaced to you rather than resolved blindly.

Active-use conflict policy

When a remote update arrives for a file you’ve changed locally in the last 60 seconds (configurable in advanced settings), cnfgr protects your in-flight edit:

1. It defers the write instead of applying it immediately.
2. After the defer window expires, it re-checks the file.
3. If the local file now differs from both the previously synced state and the incoming remote version, that’s a real conflict.

When a real conflict is detected, cnfgr writes the incoming remote version alongside your file as:

<filename>.cnfgr-conflict-<timestamp>.<ext>

and surfaces a notification in the UI with a Resolve button.

Resolving a conflict

The Resolve action opens a three-way merge view (powered by a CodeMirror merge editor) showing your version, the incoming version, and their common ancestor. You choose what to keep, and cnfgr writes the merged result back as the canonical record so every device converges on your decision.

Markdown bodies are never auto-merged into each other — you stay in control of the final content.

Version history & rollback

cnfgr keeps version snapshots of your configuration so you can:

• review how a record changed over time, and
• roll back to an earlier version if a change wasn’t what you wanted.

Rollback writes the chosen earlier version as the current canonical record, which then syncs out like any other edit.

Local history

Separately from synced version snapshots, cnfgr keeps a local history of recent changes on the device, which is useful for recovering an edit before it has fully propagated.