Advanced Rails - Building Industrial-Strength Web Apps in Record Time

Version Control | 297

A developer follows this basic procedure to work with a version control system:

1. Create aworking copy(a local copy of the code for development) by performing
   acheckout. This downloads the latest revision of the code.


2. Work on the code locally. Periodically issueupdatecommands, which will
   retrieve any changes that have been made to the repository since the last check-
   out or update. These changes can usually be merged automatically, but some-
   times manual intervention is required.


3. When the unit of work is complete, perform acommitto 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 ver-
sion 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. CVS introduced
thecopy-modify-mergemodel for text files. Under this model, many developers can
work on different parts of the same file concurrently, merging the changes together
upon commit.

Repository hooks
The ability to run external scripts upon commit—to run tests, notify a team,
start a build, or anything else.

Branches and modules
CVS allows multiple concurrent branches for development. Vendor branches can
pull code from unrelated projects; modules map symbolic names to groups of
files for convenience.

Figure 10-1. Centralized version control

Central repository

Working

copy

Working

copy

Working

copy

svn checkout /

svn update /

svn commit /