"Distributed Version Control
In traditional version control systems, there is a central
repository that maintains all history. Clients must interact with
this repository to examine file history, look at other branches, or
commit changes. Typically, clients have a local copy of the
versions of files they are working on, but no local storage of
previous versions or alternate branches.
"Distributed Version Control Systems (DVCS) use a different
structure. With DVCS, every user has their own local repository,
complete with project history, branches, etc. Switching to an
alternate branch, examining file history, and even committing
changes are all local operations. Individual repositories can then
exchange information via push and pull operations. A push transfers
some local information to a remote repository, and a pull copies
remote information to the local repository. Note that neither
repository is necessarily "authoritative" with respect to the
other. Both repositories may have some local history that the other
does not have yet. One key feature of any DVCS system is to make it
easy for repositories to unambiguously describe the history they
have (and the history they are requesting). Both Git and Mercurial
do this by using SHA1 hashes to identify data (files, trees,
changesets, etc).
"DVCS's provide a lot of flexibility in developer workflows.
They can be used in a manner similar to traditional VCS's, with a
central "authoritative" repository with which each developer
synchronizes. For larger projects, it is also possible to have a
hierarchy of server repositories, with maintainers for each
repository accepting changes from downstream developers and then
forwarding them upstream. DVCS's also allow developers to share
work with each other directly. For example, two developers working
on a new feature could work on a common branch and share work with
each other independent of an "authoritative" server. Once their
work was stable, it could then be pushed to a public repository for
a larger audience."