From Wikipedia, the free encyclopedia - View original article
|This article needs attention from an expert in Computer science. (August 2014)|
|This article contains embedded lists that may be poorly defined, unverified or indiscriminate. (January 2008)|
In computer programming, distributed revision control, also known as distributed version 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).
|This article possibly contains original research. (January 2008)|
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. 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:
Other differences include:
DVCS proponents point to several advantages of distributed version control systems over the traditional centralised model:
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."
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.
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:
For a list of distributed revision control systems, see the comparison of revision control software.
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.
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.
|This section requires expansion. (June 2008)|
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.
Some originally centralized systems are starting to offer distributed features. For example, Subversion is able to do many operations with no network. It may become more difficult to separate natively distributed vs centralized systems.
|This article includes a list of references, but its sources remain unclear because it has insufficient inline citations. (July 2008)|