300 | Chapter 10: Large Projects
can “check out” a codebase (hg clone), make modifications, update from the reposi-
tory (hg pull;hg merge), and check in (hg commit). This process is illustrated in
Figure 10-2.
There is a slight difference here from the centralized paradigm, in that the pull and
merge steps are second. Mercurial gives the developer complete control over the
local repository and working copy, so merges do not take place unless requested.
The real power comes from the ability to synchronize repositories. Changesets can
be pulled from any repository, not just the master. So, if Bob developed a feature that
Alice needs to test, Alice can pull it directly from him, merge it into her repository,
and test it before committing it to the master. This is most commonly done today
with centralized systems usingdiffandpatch, but distributed systems formalize this
method. The process looks something like Figure 10-3.
One of the most compelling features of decentralized version control is its compati-
bility with offline development. With a centralized system, the developer must be
Figure 10-2. Decentralized version control
Figure 10-3. A repository can pull from or push to any other repository
hg clone /
hg pull /
hg merge /
hg commitAuthoritative
repositoryLocal repository:
AliceLocal repository:
BobLocal repository:
CarolAuthoritative
repositoryhg pull /
hg mergeLocal repository:
AliceLocal repository:
BobLocal repository:
Carol