Conflict Resolution
When multiple agents or users modify the same data at the same time, PuppyOne provides a complete system for detecting and resolving conflicts.
The challenge of concurrent editing
In multi-agent collaboration, concurrent conflicts are unavoidable:
- Agent A is updating
/specs/api-design.mdwhile Agent B edits the same file at the same time - You are editing a JSON file in the Dashboard while a sync connection is pulling fresh data from Notion
- Two agents modify content under the same folder through MCP
Without a conflict management mechanism, the later write silently overwrites the earlier one, causing data loss.
PuppyOne's Solution
PuppyOne offers three conflict resolution strategies for different scenarios:
┌──────────────────────┬──────────────────────┬──────────────────────┐
│ Checkout / Commit │ Three-way Merge │ Last-write-wins │
│ Pessimistic lock │ Optimistic merge │ Latest write wins │
│ │ │ │
│ Lock before edit. │ Auto-merge on │ Timestamps decide │
│ Other writers │ commit. Conflicts │ the winner. Older │
│ must wait. │ marked for review. │ version kept in │
│ │ │ history. │
│ │ │ │
│ Best for: │ Best for: │ Best for: │
│ critical data │ collaborative edit │ file sync │
└──────────────────────┴──────────────────────┴──────────────────────┘1. Checkout / Commit (Pessimistic Locking)
Lock first, edit second, commit last. While the node is locked, nobody else can modify it.
This is best for scenarios with strict consistency requirements, such as editing API spec docs or updating critical configuration.
2. Three-Way Merge
No locking. Multiple actors can edit at the same time. On commit, the system compares the base version and both sets of changes, then tries to merge them intelligently:
- Non-conflicting changes are merged automatically
- Conflicting parts are marked for human review
This is well suited to collaborative editing.
3. Last-write-wins
The simplest strategy: the later write directly overwrites the earlier one. The overwritten content is automatically preserved in version history and can be rolled back at any time.
This is the default strategy for OpenClaw local folder sync.
How to choose a strategy
| Scenario | Recommended Strategy | Why |
|---|---|---|
| Editing critical config files | Checkout/Commit | Guarantees exclusive editing and avoids conflicts |
| Multiple agents co-authoring docs | Three-way Merge | Allows parallel work and auto-merges safe changes |
| Local folder sync | Last-write-wins | Simple, efficient, backed by version history |
| Syncing from a data source | Last-write-wins | The external source is the system of record |
| Agents updating important business data | Checkout/Commit | Prevents data loss from concurrent writes |