*
At first glance, a distributed workflow might look fairly similar to a centralized one.
In fact, a decentralized version control system can be used as a centralized system; its
functionality is a superset of that of centralized systems. Using Mercurial, a developer
* http://www.selenic.com/mercurial/wiki/index.cgi/KernelPractice
300 | Chapter 10: Large Projects
can ???check out??? a codebase (hg clone), make modifications, update from the repository
(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 using diff and patch, 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 compatibility
with offline development.
Pages:
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456