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
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
0 comments:
Post a Comment