Article development led by
queue.acm.org
All revision-control systems come with
complicated sets of trade-offs. How do you
find the best match between tool and team?
BY BRYaN o’SuLLiVaN
making Sense
of Revision-
control
Systems
ModErn soFtwarE is tremendously complicated,
and the methods that teams use to manage its
development reflect this complexity. Though many
organizations use revision-control software to track
and manage the complexity of a project as it evolves,
the topic of how to make an informed choice of
revision-control tools has received
scant attention. Until fairly recently,
the world of revision control was moribund, so there was simply not much to
say on this subject.
The past half-decade, however, has
seen an explosion of creativity in revision-control software, and now the
leaders of a team are faced with a bewildering array of choices.
ILLUs TRATIon By LEAnDER HERZoG
Concurrent Versions System (CVS)
was the dominant open source revision-control system for more than a
decade. While it has a number of severe
shortcomings, it is still in wide use as a
legacy system. Subversion, which was
written to supplant CVS, became popular in the mid-2000s. (Perforce is a nota-
ble commercial competitor to Subversion) Both Subversion and CVS follow
the client-server model: a single central
server hosts a project’s metadata, and
developers “check out” a limited view
of this data onto the machines where
they work.
In the early 2000s, several projects
began to move away from the centralized development model. Of the initial
crop of a half-dozen or so, the most popular today are Git and Mercurial. The
distinguishing feature of these distributed tools is that they operate in a peer-to-peer manner. Every copy of a project
contains all of the project’s history and
metadata. Developers can share changes in whatever arrangement suits their
