1.4 A few of the advantages of distributed revision control
Even though distributed revision control tools have for several years
been as robust and usable as their previousgeneration
counterparts, people using older tools have not yet necessarily woken
up to their advantages. There are a
number of ways in which distributed tools shine relative to
centralised ones.
For an individual developer, distributed tools are almost always much
faster than centralised tools. This is for a
simple reason: a centralised tool needs to talk over the network for
many common operations, because most metadata
is stored in a single copy on the central server. A distributed tool
stores all of its metadata locally. All else being equal,
talking over the network adds overhead to a centralised tool. Don’t
underestimate the value of a snappy, responsive
tool: you’re going to spend a lot of time interacting with your
revision control software.
Distributed tools are indifferent to the vagaries of your server
infrastructure, again because they replicate metadata
to so many locations. If you use a centralised system and your server
catches fire, you’d better hope that your backup
media are reliable, and that your last backup was recent and actually
worked. With a distributed tool, you have many
backups available on every contributor’s computer.
The reliability of your network will affect distributed tools far less
than it will centralised tools. You can’t even use
a centralised tool without a network connection, except for a few
highly constrained commands. With a distributed
tool, if your network connection goes down while you’re working, you
may not even notice. The only thing you
won’t be able to do is talk to repositories on other computers,
something that is relatively rare compared with local
operations. If you have a far-flung team of collaborators, this may be
significant.
1.6.3 CVS
CVS is probably the most widely used revision control tool in the
world. Due to its age and internal untidiness, it has
been only lightly maintained for many years.
It has a centralised client/server architecture. It does not group
related file changes into atomic commits, making it
easy for people to “break the build”: one person can successfully
commit part of a change and then be blocked by the
need for a merge, causing other people to see only a portion of the
work they intended to do. This also affects how you
work with project history. If you want to see all of the modifications
someone made as part of a task, you will need to
manually inspect the descriptions and timestamps of the changes made
to each file involved (if you even know what
those files were).
CVS has a muddled notion of tags and branches that I will not attempt
to even describe. It does not support
renaming of files or directories well, making it easy to corrupt a
repository. It has almost no internal consistency
checking capabilities, so it is usually not even possible to tell
whether or how a repository is corrupt. I would not
recommend CVS for any project, existing or new.
Mercurial can import CVS revision history. However, there are a few
caveats that apply; these are true of every
other revision control tool’s CVS importer, too. Due to CVS’s lack of
atomic changes and unversioned filesystem
hierarchy, it is not possible to reconstruct CVS history completely
accurately; some guesswork is involved, and renames
will usually not show up. Because a lot of advanced CVS administration
has to be done by hand and is hence
error-prone, it’s common for CVS importers to run into multiple
problems with corrupted repositories (completely
bogus revision timestamps and files that have remained locked for over
a decade are just two of the less interesting
problems I can recall from personal experience).
Mercurial can import revision history from a CVS repository.
1.6.5 Choosing a revision control tool
With the exception of CVS, all of the tools listed above have unique
strengths that suit them to particular styles of
work. There is no single revision control tool that is best in all
situations.
As an example, Subversion is a good choice for working with frequently
edited binary files, due to its centralised
nature and support for file locking. If you’re averse to the command
line, it currently has better GUI support than
other free revision control tools. However, its poor merging is a
substantial liability for busy projects with overlapping
development.
I personally find Mercurial’s properties of simplicity, performance,
and good merge support to be a compelling
combination that has served me well for several years.