Multiuser Subversion

Installing a Subversion Server

In a
previous article, we saw how to install and use Subversion, in the context
of a single user, and use it on a single system. This article will take you one
step beyond and show how to install a Subversion server, accessible via the
network and to a team of users. We'll see also how Subversion can help to
manage a project to which several developers contribute.

Subversion uses Apache as its HTTP transport layer. The command-line client
communicates with remote servers with a protocol built on the WebDAV/DeltaV
HTTP 1.1 extensions. This means that a Subversion server, while not completely
implementing WebDAV, can respond to common HTTP and WebDAV (read-only) clients
such as Web browsers and file explorers.

Building a Subversion-powered Apache server

You'll need a recent version of Apache 2 to build a Subversion server. The
build process is obviously a bit more complex than for a stand alone client, as
you should build an Apache with the specific module mod_dav_svn.
That's why I'll detail the necessary steps.

As in my previous article, I'll assume you're building from a source
snapshot on an Unix platform and that you will install everything under
/usr/local/subversion-rXXXX (where XXXX is the
revision number of the snapshot you're using, this directory being linked from
/usr/local/subversion). This directory layout makes it easier to
upgrade Subversion, an important point when using a software that has not
reached a stable version yet. In this case, make sure your system can find
shared libraries in /usr/local/subversion/lib. (To build
Subversion from the latest sources, refer to the INSTALL file, which explains
how to checkout and compile from the development server.) At the time of this writing, the current stable version is 0.16, revision number 3987.

The first step is to set up the subversion directory and build the database.
As of subversion 0.15, you will need the Berkeley DB, version 4.0.14. If it's not installed on your system, install it in the same directory as Subversion.

Then, install Apache. You should get at least version 2.0.42. The
--enable-dav option will build and include mod_dav and
--enable-so will enable DSO (Dynamic Shared Object) support. The
other options specify that Apache will be installed with Subversion and will
use the Berkeley DB you've just built, an important point.

Finally, compile and install Subversion. The important option here is
--with-apxs, giving the path to the apxs(8) tool,
used to build and install Apache extension modules. In this case, the
installation process should install mod_dav_svn, the Apache
module that handles requests from Subversion clients.

Configuring the Server

To enable some URLs to be handled by mod_dav_svn, you only have
to add in the httpd.conf file:

<Location /svn>
DAV svn
SVNPath /home/rafael/svn
</Location>

This block tells Apache to serve paths that begin with /svn via
mod_dav_svn, and that they map to the Subversion repository kept
at the physical location /home/rafael/svn. To check out a working
copy of the trunk of the frobnizer project from this repository,
the appropriate command becomes:

$ svn checkout http://my.host/svn/frobnizer/trunk work-dir

By default, Apache listens on port 80, and this means that it must be
started by the root user. You can change this if you want. Note, however, that
the Apache processes must be able to write to the Subversion repository. One of
the clean ways to do this is to create an account svn, on your
system, to own the Subversion repository. Configure Apache to run as this user
via the User configuration directive. Once you've done this,
you're ready to start the server:

$ /usr/local/subversion/bin/apachectl start

To restrict read or write access to your repository, you can use Apache's
access control features. You can limit the hosts that are allowed to access the
repository and require a username and a password for some operations (via HTTP
authentication). For example, the following lines, inserted in the <Location> block, limit write access to a specific group of users:

This specifies that all requests but those using the listed HTTP methods
should be issued by a authenticated user, a member of the commiters
group. (See http://httpd.apache.org/docs-2.0/mod/core.html for a detailed description of access control and of the related
configuration directives.) When the commit has been done via HTTP, the
Subversion-generated change logs will record the HTTP username.

Note that the Subversion client caches your username and password in your
working copy by default, so you won't have to enter it each time you access the
repository. If you're worried about security, you can disable this behavior
via the user configuration file $HOME/.subversion/config or in the
global configuration file /etc/subversion/config on the client
machine.

If you want to deploy Subversion in your organization, you may find it
easier to compile a statically linked svn client. This way, you
only have to copy this binary file to the users machines, without having to
install the required libraries. (You'll need, however, to compile this client
separately using the --enable-all-static configure option. It's
not possible to build a statically linked svn and
mod_dav_svn at the same time. The Apache module needs to be built
as a shared library.)

Collaborative Use of Subversion

When several users have commit access to the Subversion repository, they
need, at some point, to integrate in their working copies the changes committed
by others. The svn update command performs this task, updating its
targets (by default, the current directory and its contents, recursively) to
the latest revision.

What happens when you update a file that you've edited locally, but on which
another user has committed his own edits? If you've read the first article, you
already know that Subversion doesn't require that you lock a file when you want
to modify it. This behavior is different from some other source control
software that prevent you from editing a file that has been reserved by
another user. Subversion attempts to merge the changes you've made with the
ones made by others.

While performing an update, svn will print a list of updated
files, marking each line with a letter to indicate the action taken on the
corresponding file. It was (A)dded, (D)eleted, (U)pdated, and, when your local
copy has changes, they have been mer(G)ed, or the file remains in a
(C)onflicted state. For example, the following output:

U foo.c
G bar.c
C hot.c

indicates that foo.c was updated, and that it didn't have any
local change. Your local edits to bar.c were successfully merged.
Subversion didn't know how to merge on hot.c, because the
server's changes overlapped with yours.

In this last case, Subversion will create three temporary files containing
your local version, the repository version you used as a basis for your edits,
and the latest version from the repository. Your original file will be modified
as well: mergeable changes will be merged, and other changes will be indicated
with conflict markers similar to those inserted by the diff3(1)
command (specifically, diff3 -E).

You will then have to resolve those conflicts manually and delete the
temporary files. (To protect against unwanted commits, Subversion will not let
you commit a file when it detects this temporary file lying around.) For
convenience, the svn resolve command deletes those temporary files
for you.

Note also that Subversion will not let you commit files for which a more
recent revision exists. You'll need to update them first.