Version Control | 299Subversion provides the best fit for many developers, especially in the open source
world. Many projects have migrated from CVS to Subversion over the past few years.
Subversion is successful in a large part because it strikes a good balance between fea-
tures and ease of use.
One drawback of Subversion is that it can be difficult to build the server from source
because of its dependencies. It is built on top of APR (the Apache Portable Run-
time), a portability layer for network applications. Although the basic dependencies
are included for a svnserve installation, you may run into difficulty if you want to use
Apache as a Subversion server. However, once you have the dependencies in order,
building the server is straightforward.
Decentralized Version Control
Centralized version control has some drawbacks, especially when working in larger
teams. The central server and repository can become a bottleneck, especially when
dealing with many developers, as in large open source projects. A new paradigm,
decentralized version control, is attempting to fix some of these issues. Though it is
not widely used among Rails developers, it is worth knowing about, as it is extremely
useful for certain situations.
In contrast to the hierarchical structure of centralized versioning systems, decentral-
ized systems provide a more egalitarian approach. (It’s the cathedral versus the
bazaar, if you will.) Rather than having many working copies that all must communi-
cate their changes back to the repository, each working copy is in fact a full reposi-
tory. Any of the local repositories can pull and push changes to and from each other,
and changesets destined for production will ultimately be pushed back to the author-
itative repository.
In fact, the only thing that designates a repository as authoritative is community sup-
port: project administrators set up a repository as the master and publish its net-
work address. Developers can pull changes from any repository that decides to
publish them. Interestingly, this parallels the meritocracy inherent in open source
software: your worth is measured by how much you contribute and how many peo-
ple listen to you.
The decentralized development model can be more complicated to learn, but it is
much more flexible, especially with large projects that have many contributors. The
Mercurial wiki gives an example of distributed development best practices based on
the development style of the Linux kernel.*
At first glance, a distributed workflow might look fairly similar to a centralized one.
In fact, a decentralized version control system can be used as a centralized system; its
functionality is a superset of that of centralized systems. Using Mercurial, a developer
*http://www.selenic.com/mercurial/wiki/index.cgi/KernelPractice