Distributed version control

In computer programming, distributed version control, also known as distributed revision control or decentralized version control, allows many software developers to work on a given project without requiring them to share a common network. The software revisions are stored in a distributed revision control system (DRCS), also known as a distributed version control system (DVCS).

Distributed vs. centralized

Distributed revision control takes a peer-to-peer approach to version control, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a complete repository.^[1] Distributed revision control synchronizes repositories by exchanging patches (sets of changes) from peer to peer. This results in some important differences from a centralized system:

• No canonical, reference copy of the codebase exists by default; only working copies.
• Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.^[2]
• Communication is only necessary when sharing changes among other peers.
• Each working copy effectively functions as a remote backup of the codebase and of its change-history, protecting against data loss.^[2]

Other differences include:

• Multiple "central" repositories.
• Code from disparate repositories is merged based on a web of trust, i.e., historical merit or quality of changes.
• Numerous different development models are possible, such as development / release branches or a Commander / Lieutenant model, allowing for efficient delegation of topical developments in very large projects.^[3] Lieutenants are project members who have the power to dynamically decide which branches to merge.
• Network is not involved for common operations.
• A separate set of "sync" operations are available for committing or receiving changes with remote repositories.

DVCS proponents point to several advantages of distributed version control systems over the traditional centralised model:

• Allows users to work productively when not connected to a network.
• Makes most operations much faster.
• Allows participation in projects without requiring permissions from project authorities, and thus arguably better fosters culture of meritocracy instead of requiring "committer" status.
• Allows private work, so users can use their changes even for early drafts they do not want to publish.
• Avoids relying on one physical machine as a single point of failure.
• Permits centralized control of the "release version" of the project
• On FLOSS software projects it is much easier to create a project fork from a project that is stalled because of leadership conflicts or design disagreements.

Software development author Joel Spolsky, the owner of a commercial DVCS, described distributed version control as "possibly the biggest advance in software development technology in the [past] ten years."^[4]

A disadvantage is that initial cloning of a repository is slower as compared to centralized checkout, because all branches and revision history are copied. This may be significant if access speed is slow and the repository size is large enough. For instance, the size of the cloned git repository (all history, branches, tags, etc.) for the Linux kernel is approximately the size of the checked-out uncompressed HEAD, whereas the equivalent checkout of a single branch in a centralized checkout would be the compressed size of the contents of HEAD (except without any history, branches, tags, etc.). Another problem with DVCS is the lack of locking mechanisms that is part of most centralized VCS and still plays an important role when it comes to non-mergable binary files such as graphic assets.

Systems

Open systems

An "open system" of distributed revision control is characterized by its support for independent branches, and its reliance on merge operations. Its general characteristics include:

• Every working copy is effectively a fork.
• The system implements each branch as a working copy, with merges conducted by ordinary patch exchange, from branch to branch.
• Code forking therefore occurs more readily, where desired, because every working copy is a fork. (As well, undesirable forks are easier to mend because, if the dispute can be resolved, re-merging the code is easy.)
• It may be possible to "cherry-pick" single changes, selectively pulling them from peer to peer.
• New peers can freely join, without applying for access to a server.

For a list of distributed revision control systems, see the comparison of revision control software.

Replicated systems

A replicated system of distributed revision control depends on a replicated database. A check-in is equivalent to a distributed commit. Successful commits create a single baseline, which reduces the need for merges. An example of a replicated distributed system is Code Co-op.

Work model

The distributed model is generally better suited for large projects with partly independent developers, such as the Linux kernel project, because developers can work independently and submit their changes for merge (or rejection). The distributed model flexibly allows adopting custom source code contribution workflows. The integrator workflow is the most widely used.

In the centralized model, developers must serialize their work, to avoid problems with different versions.

History

Closed source DVCS systems such as Sun WorkShop TeamWare were widely used in enterprise settings in the 1990s and inspired BitKeeper (1998), one of the first open systems. BitKeeper went on to serve in the early development of the Linux kernel.

First generation open-source DVCS systems include Arch and Monotone. The second generation was initiated by the arrival of Darcs, followed by a host of others.

When the publishers of BitKeeper decided in 2005 to restrict the program's licensing,^[5] free alternatives Bazaar, Git, and Mercurial followed not long after.

Future

Some originally centralized systems now offer some distributed features. For example, Subversion is able to do many operations with no network.^[6]

See also

References

External links

• Essay on various revision control systems, especially the section "Centralized vs. Decentralized SCM"
• Introduction to distributed version control systems - IBM Developer Works article

Version control software Years, where available, indicate the date of first stable release. Systems with names in italics are no longer maintained or have planned end-of-life dates. Local only Free/open-source SCCS (1972) RCS (1982) Proprietary PVCS (1985) QVCS (1991) Client–server Free/open-source CVS (1986, 1990 in C) CVSNT (1998) QVCS Enterprise (1998) Subversion (2000) Proprietary Software Change Manager (1970s) Panvalet (1970s) Endevor (1980s) Dimensions CM (1980s) DSEE (1984) Synergy (1990) ClearCase (1992) CMVC (1994) Visual SourceSafe (1994) Perforce (1995) StarTeam (1995) Integrity (2001) Surround SCM (2002) AccuRev SCM (2002) SourceAnywhere (2003) Vault (2003) Team Foundation Server (2005) Team Concert (2008) Distributed Free/open-source GNU arch (2001) Darcs (2002) DCVS (2002) ArX (2003) Monotone (2003) SVK (2003) Codeville (2005) Bazaar (2005) Git (2005) Mercurial (2005) Fossil (2007) Veracity (2010) Proprietary TeamWare (1990s?) Code Co-op (1997) BitKeeper (1998) Plastic SCM (2006) Concepts Branch Fork Changeset Commit Interleaved deltas Delta compression Data comparison Merge Repository Tag Trunk Category Comparison List