Distributed VCS Concepts

## What a clone actually contains A repository in a distributed version-control system is two things kept side by side. The first is an **object store**: an append-only collection of immutable records holding every version of every file the project has ever contained, plus the records that chain those versions into a history. Objects are addressed by a hash derived from their own content, so identical content always lands in the same place and a copy can be checked for integrity without asking anyone. The second is a set of **pointers**: short, movable names — a line of development, a name for a fixed point in history — that record where in that history something currently sits. Copying the repository transfers both. That is the structural difference from a centralized model, where what arrives on your machine is a **working copy**: the files as of one chosen revision, plus enough bookkeeping to ask the server about everything else. In a distributed system there is no everything-else living somewhere you cannot reach. Your copy is a peer of the copy you took it from, identical in kind, differing only in where its pointers sit and which recorded changes it holds that the other does not. ## The four things completeness buys 1. **Offline work.** Reading history, comparing two old revisions, finding when a line of a file changed, creating a line of development and recording a change are all reads and writes against local storage. A network is needed only to exchange work with another copy. 2. **No single point of failure.** History is replicated as a side effect of working. If the machine hosting the shared copy is lost, any complete copy still holds the history up to what it last received and can become the new shared copy. 3. **Cheap local experimentation.** Creating a line of development writes one small pointer, and nothing you record is visible to anyone until you publish it, so trying an idea and throwing it away costs only your own disk. There is no shared namespace to pollute and nothing to clean up in public. 4. **Publishing is a deliberate act.** Recording a change and sharing it are separated, which is the same property seen from the other side: your copy diverges on purpose and you choose when it converges again. ## Where the cost lands | Operation | Centralized working copy | Distributed full copy | |---|---|---| | Read the history of a file | server round trip | local | | Compare two old revisions | server round trip | local | | Create a line of development | created centrally, visible to all | local, private until published | | Record a change | enters the shared sequence at once | local; publishing is a separate act | | First copy of the project | one revision's worth of files | every version ever recorded | | Shared copy unreachable | most work stops | only exchange stops | | Shared copy lost | restore from backups | any full copy can reseed it | The last two rows are the payoff and the first-copy row is the price. On a charity donation platform whose shared copy was unreachable for 43 minutes during a seasonal traffic peak, no engineering time was lost: 12 people kept recording changes, reading history and preparing work, and the exchange queue drained when the host returned. The same repository's first copy moves the whole history, including versions of files deleted years earlier, which is why the cost of completeness shows up on old, large or asset-heavy projects and almost nowhere else. ## What completeness does not give you Being complete is a statement about the past, not about the present. Your copy holds everything it has received; it says nothing about what a teammate recorded ten minutes ago and has not published. Two consequences are easy to miss. - **Replication is redundancy, not a backup policy.** Developer copies drift, they never contain unpublished work, and they faithfully replicate a destructive rewrite the moment they receive it. Redundancy with no retention, no verification and no restore drill is not a backup. - **Completeness coordinates nobody.** Holding the whole history does not tell you which copy the team treats as authoritative, whether a change has been accepted, or whether someone else is already editing the file you just opened. Those are conventions and services layered on top of the model. A 14-month-old line of development on that donation platform shows both at once: every copy that ever received it still holds it in full, which is why nothing was lost — and no copy can say whether the team still wants it, which is why nothing was decided.