Content deleted Content added
Avoid relying on a single physical server. |
MicahElliott (talk | contribs) Added more content, including new sections |
||
Line 1:
'''Distributed revision control''' (or '''Distributed Version Control (Systems) (DVCS)''', or '''Decentralized Version Control''') is a fairly recent innovation in [[Computer software|software]] [[revision control]]. It provides some significant advantages over the more traditional centralized approach to revision control, and it has some defining characteristics that separate it from centralized systems. However, the line between distributed and centralized systems is graying in some regards, especially since DVCSs can be used in a "centralized mode".
==Main Differences From Centralized==
* Each developer does work on her own local [[Software repository|repository]].
* Working model epitomizes [[The Cathedral and the Bazaar|bazaar]]-style development in that ''anyone'' can create their own [[Branching (software)|branch]].
* Repositories are [[Repository clone|cloned]] by anyone, and are often cloned many times.
* There may be many "central" repositories.
* [[Access control list]]s are not employed. Instead code from disparate repositories are [[Merge (revision control)|merged]] based on a [[circle of trust]], i.e., historical merit or quality of changes.
* Network is not involved in most opererations.
* A separate set of "sync" operations are available for commiting or receiving changes with remote repositories.
==Advantages vs Centralized==
* 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 instead of requiring "committer" status.
* Allows private work, so you can use your revision control system even for early drafts you don't want to publish
* Avoids relying on a single physical machine. A server disk crash is a non-event with Distributed revision control
==Disadvantages vs Centralized==
* Many teams have long used and grown accustomed to the centralized model, and are reluctant to change
* [[Source code]] is considered the "crown jewels" of a software group. Centralized VCSs have been around much longer and thus perceived to be more stable
* Some projects want or need centralized control
* Distributed systems can end up with a person as the central point of control, rather than a server
* Concepts of DVCSs are slightly more difficult for developers to grasp. They become required to know more about infrastructure.
==Work Model==
The distributed model also impacts the traditional developer working model.
==History==
GNU Arch and Monotone were the early systems to embrace DVCS principles.
Now the line is graying
==See also==
* [[List of revision control software]]
==Flourishing DVCSs==
* [http://www.selenic.com/mercurial/ Mercurial]
* [http://git.or.cz/ git]
* [http://bazaar-vcs.org/ Bazaar-NG]
* [http://svk.bestpractical.com/ SVK]
* [http://subversion.tigris.org Subversion] (it is growing some distributed features, like local commits, but is really a centralized VCS)
==External links==
* [http://www.dwheeler.com/essays/scm.html Essay on various revision control systems], especially the section "Centralized vs. Decentralized SCM"
* [http://lwn.net/Articles/246381/ Linus Torvalds describing DVCS to KDE developers]
* [http://www.youtube.com/watch?v=4XpnKHJAok8 Controverial Torvalds video]
* [http://video.google.com/videoplay?docid=-7724296011317502612 Bryan O'Sullivan on Mercurial]
* [http://blog.red-bean.com/sussman/?p=20 Ben Collins-Sussman on "The Risks of Distributed Version Control"]
{{software-stub}}
| |||