Though the former is the most widely known, the latter is steadily gaining in
popularity and has some amazing capabilities.
Centralized Version Control
Centralized version control is the most popular model, and perhaps the easiest to
understand. In this model, there is a central repository, operated by the project
administrators. This repository keeps a virtual filesystem and a history of the changes
made to that filesystem over time.
Figure 10-1 illustrates the typical working model used for centralized development.
Version Control | 297
A developer follows this basic procedure to work with a version control system:
1. Create a working copy (a local copy of the code for development) by performing
a checkout. This downloads the latest revision of the code.
2. Work on the code locally. Periodically issue update commands, which will
retrieve any changes that have been made to the repository since the last checkout
or update. These changes can usually be merged automatically, but sometimes
manual intervention is required.
3. When the unit of work is complete, perform a commit to send the changes to the
repository. Repeat from step 2, as you already have a working copy.
CVS
The Concurrent Versions System (CVS, http://www.nongnu.org/cvs/) is the oldest version
control system still in common use. Although Subversion is generally favored as
its replacement, CVS pioneered several features considered essential to centralized
version systems, such as the following:
Concurrent access
Previous version control systems such as RCS required a developer to ???check out??? a
file, locking it for update, and then check it in to release the lock.
Pages:
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451