Why version control went distributed

1972 to 2000What version control was before

The earliest systems tracked one file at a time and used locking: to edit, you took a lock, and everybody else waited. That was reasonable when a change touched one file and a team shared one machine.

The next generation removed the lock and allowed concurrent edits, still file by file, which meant a change spanning several files was not recorded as one thing. The generation after that made the change atomic and kept everything else: one server, one history, and permission required to write.

2000sWhat distribution actually changes

Every copy holds the entire history, and recording a change is a local operation that asks nobody.

The technical consequences are pleasant and secondary: work continues without a network, and history can be tidied before it is shown to anyone. The consequence that mattered is social.

Contribution without permission

Under a central system, a stranger cannot record work at all. They can produce a patch, but the history of their attempts, their false starts and their revisions exists only on their own disk in whatever form they improvised.

Under a distributed one, a stranger has a complete repository from the first minute, with the same tools and the same history as anybody else, and the question of whether their work is accepted is separated entirely from whether they may record it. That separation is what made the modern contribution model possible.

Merging as the normal case

Systems built around locking treat divergence as a failure to be prevented. Systems built around distribution cannot prevent it, because everybody diverges by construction, so merging had to become routine.

That forced the tooling to get good at it, and once merging was cheap the whole workflow rearranged around branches: one per feature, one per fix, one per experiment, all of which were prohibitively awkward when a branch was a server-side operation and a merge was an afternoon.

What it cost

The model is harder. A user must understand that the copy, the recorded state and the published state are three different things, and that operations exist which change history rather than adding to it.

The result is a tool that is used by a large majority of practitioners and understood well by a minority, with an entire secondary literature explaining how to escape from states the model permits and the interface does not explain.

2010sThe centralisation that came back

Worth saying plainly, because it is the most interesting thing about the outcome. The distributed model won and then recentralised: nearly all of its use now revolves around a small number of hosting services that hold the authoritative copy, the discussion, the review and the automation.

What distribution actually preserved is the ability to leave. The history is genuinely in every copy, so a project can move hosts in an afternoon and lose only the things layered on top, which is exactly the part that is not distributed.

Content addressing underneath

The property that makes the distributed model work is that a recorded state is named by a hash of its contents rather than by a number assigned by a server.

Two people can therefore record work without coordinating and without colliding, and any copy can verify that what it received is what was sent. Sequential revision numbers, which the central systems used, require exactly the central authority the model was removing.

What history rewriting really is

Because a recorded state is identified by its contents, changing anything about it produces a different state rather than modifying the old one. Rewriting history is therefore always the creation of a parallel history and the abandonment of the original.

That explains the sharp division in practice between tidying work nobody else has seen, which is harmless, and doing the same to something others have copied, which strands them on a history that no longer exists anywhere else.

2000s onwardsThe workflow that had to be invented

None of the mechanics say what to do with a contribution once it exists. The review-before-merge arrangement now standard was built on top by hosting services, not by the tool, and it is a social protocol with an interface attached.

Which is why it varies so much between projects using identical software, and why arguments about it are never resolved by reading the documentation.

1972 onwardsWhat the earlier systems did better

Worth conceding, because the winning story usually omits it. Locking made it impossible for two people to be surprised by each other, which for binary files that cannot be merged is not a limitation but the only workable arrangement.

Distributed systems handle those badly to this day, and projects with large unmergeable assets either bolt a locking mechanism back on or keep a second system alongside. The model that won suits text, and a great deal of work is not text.

What did not change

None of this settled how to structure a change, how large a recorded step should be, or what a description of one should say. Those are conventions, they differ per project, and the tool is indifferent to all of them.

Which is the recurring shape in this part: the mechanism that won made a category of work cheap, and the judgement about how to do the work stayed exactly where it was.

What we cannot verify

The systems, their dates and their models are documented and can be checked. Claims about why any particular project adopted one tool over another are usually reconstructed afterwards, and the adoption of the dominant system owes a great deal to circumstances that had nothing to do with its model.