A VersionControlSystem that uses inter-repository replication as the mechanism for collaboration. Each participant has a full copy of the repository and can exchange changesets freely with any other participant. Examples include Git, Mercurial, Bazaar and darcs.

This stands in contrast to a centralised VersionControlSystem, where there is only one repository stored on a central server, which serves as the hub for any collaboration: participants must push commits to this server and must fetch others' commits from it. This has many drawbacks:

• Inability to work offline (with no access to the central server). While you can keep a working copy of the source tree, there is no way to maintain a private history of commits and branches.
• Inability to exchange changesets between different groups working on different (or related) parts of the source tree, unless these changesets are made part of the official history recorded by the central server.

Those accustomed to working with centralized VCSs may view the above as virtues rather than drawbacks; project-management culture has a lot to do with how the differences are perceived. However, it should be noted that DVCSs support centralised workflows just as well as centralised systems do; the difference is that they also support decentralised workflows.

Lack of support for decentralised workflows might seem like a technical way of enforcing a centralised workflow. However, almost every DVCS supports two-way bridging with at least SubVersion, and patch-based distributed workflows are possible with any VCS. The effective question becomes how cleanly history can be tracked, should developers find themselves temporarily having to collaborate peer-to-peer in avoidance of the central repository.

EricRaymond's essay Understanding Version Control is a good backgrounder on VCS concepts.

CategoryVersionControl