needs, instead of through a central
server.
Whether centralized or distributed,
a revision-control system allows members of a team to perform a handful of
core tasks:
It allows a team to track the history ˲
of the files they work on during the development of a project. People can see
who made a change; understand when
and why it was made; inspect the details
of the change; and re-create the state of
the project at the time the change was
made.
People can work on independent ˲
subprojects without being disturbed
by other people’s changes and without
affecting the work of their colleagues.
These self-contained lines of development are usually referred to as
branches. Branches are also used to manage
the maintenance of releases that are no
longer actively developed.
When the work on a subproject is
complete, it can be integrated back into
the larger project. This is referred to as
merging.
Each revision-control tool emphasizes a distinct approach to working and
collaboration. This in turn influences
how a team works. As a result, no revision-control tool will suit every team:
each tool comes with a complicated set
of trade-offs that can be difficult even to
see, much less to evaluate.
Branches and merging:
Balancing Safety and Risk
On a large project, managing concurrent development is a substantial sticking point. Developers are sadly familiar
with progress on their feature being
stalled by a bug in an unrelated module, so they prefer to manage this risk
by working in isolated branches. When
a branch is sequestered for too long,
a different kind of risk arises: that of
teams working in different branches
making conflicting changes to the
same code.
Merging changes from one branch
into another can be frustrating and
dangerous—one that can silently reintroduce fixed bugs or create entirely
new problems. These risks can arise in
several ways:
Developers working in separate ˲
branches may modify the same sections
of one or more files in different ways.
A revision-control system will identify
The major
difference between
Subversion and
the distributed
tools is this:
with Subversion,
committing
a change implicitly
publishes it,
whereas with
the distributed
tools, the two
are decoupled.
these sections as conflicts that need to
be resolved by hand. Whoever resolves
the conflict must choose one branch’s
version, the other, or a hybrid.
Code in one branch may depend on ˲
functionality that has changed in the
other branch. In many cases, this dependency will be obvious: it will lead to
a broken build. Sometimes the effects
can be much more insidious, causing
an unanticipated kind of failure.
Some systems do not cope well if ˲
files have been renamed or copied in
one branch but modified under their
old names in another. (These are more
often bugs than fundamental deficien-cies, but longstanding bugs are important in their own right.)
Since merges introduce risk beyond
the sort that normal development incurs, how a revision-control system
handles both branches and merges
is of great importance. Under Subversion, creating a new branch is a matter
of making a copy of an existing branch,
then checking out a local view of it. Although branches are relatively cheap to
create, Subversion allows several developers to work concurrently in a single
branch. Since working out of a single
branch carries no immediately obvious costs, most teams maintain few
branches.
This mode of work introduces a new
risk. Suppose Alice and Bob are concurrently working on the same files in
a single branch. Subversion treats the
history of a branch as linear: revision
103 follows revision 102 and precedes
revision 104. Alice and Bob have each
checked out a copy of revision 105 of the
branch from the server onto their own
laptops. These working copies contain
their uncommitted work, isolated from
each other until one commits his or her
changes.
If Alice commits her work first, it
will become revision 106. Subversion
will not allow Bob to commit his work
as revision 107 until he has merged his
work with Alice’s revision 106. Since
Bob cannot commit his work, what will
happen if something goes wrong with
his merge? He will have no permanent
record of what he did and faces some
scary possibilities: his work might be
lost or quietly corrupted. Because Subversion offers working out of a shared
branch as the path of least resistance,
developers tend to do so blindly with-