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-