How we rewrote sync to stop forking your files

For the first two years of Hubcove, file sync worked the way most sync tools do: whole-file comparison. If two people edited the same file while offline, we couldn't tell what changed inside it, so the safe move was to keep both copies and rename one of them 'conflicted copy'. It worked, but it meant teams doing real concurrent work — a shared spreadsheet, a shared doc outline — hit forks constantly.

The fix we shipped in 2.4.0 tracks changes at the block level instead of the file level. When the sync client uploads a change, it sends a diff against the last known-good version, not the whole file. On the server side, if two diffs touch non-overlapping regions of the same file, we merge them automatically — the same idea version control systems have used for source code for decades, applied to arbitrary files.

It's not magic for every file type. Structured text merges cleanly; a binary format like a compiled spreadsheet workbook often doesn't have a sane 'non-overlapping region' to merge, so those still fork when both sides touch the same cell range. What changed is the default outcome: most day-to-day concurrent edits — the case that used to be the annoying common one — now just work.

The rollout was staged over about six weeks, workspace by workspace, with the old whole-file path kept as a fallback whenever the diff engine wasn't confident about a merge. That fallback is still there today, quietly catching the cases the block-level path won't touch.