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.
• 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 FOSS 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 to your local machine. 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-mergeable 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.

Central and branch repositories

Every project has a central repository that is considered as the official repository, which is managed by the project maintainers. Developers clone this repository to create identical local copies of the code base. Source code changes in the central repository are periodically synchronized with the local repository.

The developer creates a new branch in his local repository and modifies source code on that branch. Once the development is done, the change needs to be integrated into the central repository.

Pull requests

Contributions to a source code repository that uses a distributed version control system are commonly made by means of a pull request. The contributor requests that the project maintainer "pull" the source code change, hence the name "pull request". The maintainer has to merge the pull request if the contribution should become part of the source base.^[5]

The developer creates a pull request to notify maintainers of a new change; a comment thread is associated with each pull request. This allows for focused discussion of code changes. Submitted pull requests are visible to anyone with repository access. A pull request can be accepted or rejected by maintainers.^[6]

Once the pull request is reviewed and approved, it is merged into the repository. Depending on the established workflow, the code may need to be tested before being included into official release. Therefore, some projects contain a special branch for merging untested pull requests.^[5][7] Other projects run an automated test suite on every pull request, and the reviewer checks that any new code has appropriate test coverage.

History

Closed source DVCS systems such as Sun WorkShop TeamWare were widely used in enterprise settings in the 1990s and inspired BitKeeper (1998). BitKeeper went on to serve in the development of the Linux kernel from 2002 to 2005.^[8]

The first open-source DVCS systems included Arch, Monotone, and Darcs. However, open source DVCSs were never very popular until Git and Mercurial appeared. The development of Git, now the world's most popular open source DVCS, was prompted by the decision of the company that made BitKeeper to rescind the free license that Linus Torvalds and some other Linux kernel developers had previously taken advantage of.^[8]

Future

Some originally centralized systems now offer some distributed features. For example, Subversion is able to do many operations with no network.^[9] Team Foundation Server and Visual Studio Team Services now host centralized and distributed version control repositories via hosting Git.

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
• Visual Studio Team Services