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 commit
Authoritative
repository
Local repository:
Alice
Local repository:
Bob
Local repository:
Carol
Authoritative
repository
hg pull /
hg merge
Local repository:
Alice
Local repository:
Bob
Local repository:
Carol
Version Control | 301
able to contact the server whenever he wants to check code in. Under the decentralized
model, a developer can check in code to his local repository on his laptop in the
Bahamas, and then push all of the changesets at once to the authoritative repository
when he has an Internet connection. This keeps the changesets clean and focused,
while not requiring a connection to the main repository on every commit. In effect,
this method creates a hierarchy of repositories (see Figure 10-4).
The primary technical drawback to distributed systems (other than their complexity)
is that each working copy is a full repository. Because each repository contains a
full change history, a checkout of a large or often-changing system can be quite large.
As an example, the Linux kernel source code is around 50 MB (bzipped), but a git
clone checkout of the same source (with history) transfers hundreds of megabytes
across the network.
Branching and Merging
In large software development projects, there is usually a need to keep multiple lines
of development separate.
Pages:
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457