39.8 How do sync and conflicts work?

Figure: compare-and-set on the version; the loser becomes a conflicted copy, not a lost edit.

• Every commit says which version it was based on (base_version). The metadata service accepts it only if that's still the latest: compare-and-set (Chapter 17's optimistic locking).
• If not, someone else changed the file first. For opaque files, the safe answer is a conflicted copy: keep both, name the second one clearly, and let the user decide. In the chapter's code, the laptop's save becomes version 2, and the phone's becomes "Reading list (phone's conflicted copy).txt". Nothing is lost.
• Devices catch up through the journal: each device remembers its cursor (the last journal entry it applied) and asks for changes after it, in order, like Chapter 38's chat sync. A third device in the chapter's code receives both the new version and the conflicted copy.
• Notifications use long-polling or WebSockets (Chapter 21), so devices learn about changes in seconds without polling constantly.

Real-time co-editing (Google Docs) is a different problem: it merges individual keystrokes with operational transforms or CRDTs instead of whole-file versions.

Memory code: "Say which version you started from; lose the race, keep both copies."