Difference between centralized version control (CVCS) and distributed version control systems (DVCS)

1) Repository

    CVCS: Have a single server that contains all the versioned files and metadata 

    DVCS: Each users working copy of the codebase is a bona-fide repository.

2) Checkout

   CVCS: A number of clients check out files from central repository 

   DVCS: Clients don’t just check out the latest snapshot of the files: they fully mirror the repository

3) Tracking latest revision

   CVCS: Everyone knows to a certain degree what everyone else on the project is doing. The trunk usually has the latest revision.

   DVCS: It is not plainly obvious.

4) Administration

   CVCS: Administrators have fine-grained control over who can do what. Here's only one place to backup and manage storage.

   DVCS: No central control. Allows participation in projects without requiring permissions from project authorities.

5) Risk

     CVCS: The single point of failure that the centralized server represents

     DVCS: If any server dies, any of the client repositories can be copied back up to the server to restore it. Every checkout is a full backup of all the data

6) Working offline

    CVCS: Couldn’t perform common operations like commits, viewing history, etc

    DVCS: Allows users to work productively even when not connected to a network.

7) Communication

    CVCS: Every operation need to communicate with server.

    DVCS: Communication is only necessary when pushing or pulling changes to or from other peers.

8) Speed

    CVCS: Common operations (commits, viewing history, revert) needs to communicate with server, hence comparatively slower. Initial checkout is faster compared to DVCS.

   DVCS: Common operations are fast, because there is no need to communicate with a central server.  Initial cloning of a repository is slower because all branches and revision history are copied.

9) Private branches

   CVCS: Private branches are supported if not restricted by admins

   DVCS: Allows private work, so users can use their revision control system  for early drafts they do not want to publish. 

10) Locking

    CVCS: Binary files can be locked to prevent changes from peers to avoid conflicts

    DVCS: Lack of locking mechanisms causes issue while changing binary files such as graphic assets.

11) Workspace size

    CVCS: Minimal space is needed since only required files are checked out from server.

    DVCS: Working with a lot of binary files ( image files ) requires a huge amount of space while checkout. No privilege's to pull selective files from repo.

12) Examples

   CVCS: Perforce, SVN, CVS and clearcase

   DVCS: git, mercurial, bazar, darcs


Emulating centralized VC in Distributed VC
- A distributed VCS can emulate a centralized one by pushing changes to one designated upstream repository after every local commit.
- Code from disparate repositories are merged based on trust i.e. historical merit or quality of changes