Distributed revision control
|
|
This article may require cleanup to meet Wikipedia's quality standards. Please improve this article if you can. (November 2007) |
|
|
The lists in this article may contain items that are not notable, encyclopedic, or helpful. Please help out by removing such elements and incorporating appropriate items into the main body of the article. (January 2008) |
|
|
It has been suggested that this article or section be merged with revision control#Distributed revision control. (Discuss) |
Distributed revision control (or Distributed Version Control (Systems) (DVCS), or Decentralized Version Control) is a fairly recent innovation in software revision control. It has some defining characteristics that separate it from centralized systems. However, the line between distributed and centralized systems is blurring in some regards, especially since DVCSs can be used in a "centralized mode".
Contents |
[edit] Distributed vs. centralized
|
|
This article may contain original research. Please improve it by verifying the claims made and adding references. Statements consisting only of original research may be removed. More details may be available on the talk page. (January 2008) |
Comparisons are often made between centralized and distributed revision control:
- There may be many "central" repositories.
- Code from disparate repositories are merged based on a web of trust, i.e., historical merit or quality of changes.
- Lieutenants are project members who have the power to dynamically decide which branches to merge.
- Network is not involved in most 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 even when not connected to a network
- Makes most operations much faster since no network is involved
- Allows participation in projects without requiring permissions from project authorities, and thus arguably better fosters culture of meritocracy[citation needed] instead of requiring "committer" status
- Allows private work, so users can use their revision control system even for early drafts they do not want to publish
- Avoids relying on a single physical machine as a single point of failure.
- Still permits centralized control of the "release version" of the project
Software development author Joel Spolsky describes distributed version control as "possibly the biggest advance in software development technology in the [past] ten years."[1]
As a disadvantage of DVCS, one could note that initial cloning of a repository is slower compared to centralized checkout, because all branches and revision history are copied. This may be relevant if access speed is low and the project 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.).
[edit] 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).
In the centralized model, developers should serialize their work, or they may have problems with different versions.
| This section requires expansion. |
[edit] History
First generation open-source DVCSes include Arch and Monotone. The second generation was initiated by the arrival of Darcs, followed by a host of others. Among them, Mercurial and Git were created as potential replacements for BitKeeper when it was pulled from free use by the Linux kernel project by its publisher. Bazaar followed not long after.
Before these, closed source DVCSes such as Sun WorkShop TeamWare (which inspired BitKeeper) were widely used in enterprise settings.
[edit] Future
Some natively centralized systems are starting to grow distributed features. For example, Subversion is able to do many operations with no network.[2] It may become more difficult to separate natively distributed vs centralized systems.
There are many tools that rely on version control, such as wikis, file systems, and text editors. Some are starting to adopt DVCS features, and even integrate with them, for example the Gazest wiki, ikiwiki.
[edit] See also
- Revision control
- List of revision control software
- Comparison of revision control software
- Category:Software using distributed revision control
[edit] References
|
|
This article includes a list of references, related reading or external links, but its sources remain unclear because it lacks inline citations. Please improve this article by introducing more precise citations where appropriate. (July 2008) |
- ^ Spolsky, Joel (2010-03-17). "Distributed Version Control is here to stay, baby". Joel on Software. http://joelonsoftware.com/items/2010/03/17.html. Retrieved 2010-06-18.
- ^ http://osdir.com/Article203.phtml
[edit] External links
- Essay on various revision control systems, especially the section "Centralized vs. Decentralized SCM"
- Linus Torvalds email describing git (DVCS) to KDE developers
- Video of a talk Linus Torvalds gave about Git
- Bryan O'Sullivan video on Mercurial
- Ben Collins-Sussman (one of Subversion's authors) article on "The Risks of Distributed Version Control"
- Distributed Version Control Systems - Why and How by Ian Clatworthy, Bazaar/Canonical
- Software Development and Version Control systems plus handouts. Emphasis on Distributed Version Control Systems (DVCS) by Jari Aalto
- Introduction to distributed version control systems - IBM Developer Works article
|
|||||||||||||||||||||||||||||||