This need exists for a few reasons:
??? Ongoing feature development will take place almost immediately after a release
is issued. If the release is buggy, the developers need a mechanism to fix the version
that was released without introducing any of the changes that were introduced
since the release.
??? A development team will often work on multiple features concurrently. It would
be a nightmare if each developer had to ensure that his half-developed, halftested
feature worked with another developer??™s half-developed, half-tested feature
every time he checked in code.
Figure 10-4. Disconnected or offline development with decentralized version control
Authoritative
repository
hg pull /
hg push
Working copy:
Bob
Local repository:
Bob hg commit /
hg update
Bob??™s working directory, managed by Mercurial
302 | Chapter 10: Large Projects
??? When creating a release for public consumption, there is often a period of testing
and evaluation. If the entire development team were frozen during this test
period, it would be very hard to get anything done.
??? A team may offer support for multiple versions of the software at the same time,
in effect making public their branching system. Bugfixes and occasionally features
must be backported to old releases of the software.
Most version control systems offer flexible branching and merging support. A branch
is an independent line of development that can be developed on its own and merged
back into the trunk.
Pages:
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458