Distributed Revision Control - Distributed Vs. Centralized

Distributed Vs. Centralized

Distributed revision control (DRCS) 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 bona fide repository. Distributed revision control conducts synchronization 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.

Rather, communication is only necessary when pushing or pulling changes to or from other peers.

• Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing natural protection against data loss.

Other differences are as follows:

• 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.
• 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.
• 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 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
• For FLOSS software projects, it becomes 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, describes distributed version control as "possibly the biggest advance in software development technology in the ten years."

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.). 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.