Subversion: Installation, Configuration — Tips and Tricks

Introduction

This article is about installing and configuring Subversion v. 1.3.x; the installation was performed under Fedora Core 4, but should not be very different under other distributions. This article will not touch upon the usual subjects — i.e., where to download Subversion and what distro-specific commands should be used to install and configure this open source version control system.

To the novice/beginner, Subversion is a version control tool from the free/open-source world, designed to replace (and completely take over) the old horse, CVS. We will not be delving in-depth into how and why Subversion works the way it is working currently, and that is not the objective of this article.

Multiple Subversion(s)

Using system commands, check whether you already have Subversion installed. If so, verify the version before proceeding to install the latest. It is quite possible to have multiple versions installed in the same system.

Multiple Subversions — v. 1.2.3 and v. 1.3.0 — are installed in this system, for example:

[ram@lemuria ~]$ whereis svnversion
svnversion: /usr/bin/svnversion /usr/local/bin/svnversion /usr/share/man/man1/svnversion.1.gz
[ram@lemuria ~]$ /usr/bin/svnversion --version
svnversion, version 1.2.3 (r15833)
   compiled Aug 26 2005, 03:42:45

Copyright (C) 2000-2005 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

[ram@lemuria ~]$ /usr/local/bin/svnversion --version
svnversion, version 1.3.0 (r17949)
   compiled May 20 2006, 23:55:41

Copyright (C) 2000-2005 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

Pre-Installation Checks

Subversion repository storage can be based on any one of the following:

FSFS-based repository storage
Berkeley DB-based storage

At the time of creating the repository, the user has the choice of using either one of the storage types to hold the repository. By default, the storage type is FSFS enabled. [1]

With Subversion, access to the repository also has multiple choices, which can be any one among the following:

local file-system access,
HTTP-based access, and,
secure shell-based access.

How does one know for which mode of "repository access" Subversion has been configured/installed? To see the answer, run the following command:

svn --version

On my system, the output from the above command looks like this:

[ram@localhost ~]$ svn --version
svn, version 1.3.1 (r19032)
   compiled Apr  4 2006, 06:38:16

Copyright (C) 2000-2006 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

Q&A: Before Installing Subversion

Take time and try to find the answers to the following questions before proceeding to install and configure Subversion.

Type of repository access required: file-system, SSH, HTTP.
Restrictions on repositories: open-to-all, restrictive access with special groups for each repository, etc.
Version of Subversion to be used, along with version of one's "httpd" server.

Whatever your answers, always create one special/common Subversion group ("svnusers") to which users can be assigned; to these users, Subversion repositories can be opened-up for access. (For example, with the common group, the repository could be a play area/scratch pad sort of setup, where "everyone" can practise Subversion and familiarise themselves with the tool.)

The next task is to create a special user ("apache") for running the "httpd" server. This user can be added to that special/common group created for the needs of Subversion.

On my system, the results look like this:

[ram@localhost ~]$ grep apache /etc/passwd
apache:x:48:48:Apache:/var/www:/sbin/nologin
[ram@localhost ~]$ grep svn /etc/group
svnusers:x:501:ram,apache,root

NOTE: The "apache" user is part of the "svnusers" group, but can be configured in such a way as to have two special groups for Subversion — one group for those that access the repositories via "http" and another for access via "file-system".

One final word on Web server "httpd". Always install the "httpd" server first, before Subversion. Subversion is built on APR (Apache Portable Runtime) libraries, which provide all the interfaces that Subversion requires for its basic functionalities on different OSes, like disk access, network access, memory management, etc.

Subversion with Apache

Pre-Installation Tips

It is always good to install Subversion from its sources. [2] In such a case, the "configure" script from the Subversion source should be run like this (assuming that the "httpd" server is already installed):

./configure --with-apr=/full/path/to/apr-config --with-apr-util=/full/path/to/apr-util-config

Post-installation Tips

After installing Subversion, I proceeded to play around with it using "http" access, but things did not happen as I expected: A quick look at the Web server logs revealed that "http" requests were failing. Thanks to people on the 'svnforum' mailing list, the problem was quickly revealed: it concerned the APR libraries used in Subversion source compilation.

Using the "ldd" command, I verified the APR libraries used in 'mod_dav_svn.so' and 'httpd', but they did not match — meaning that "httpd" and mod_dav_svn were not referring to the same APR libraries they should be.

[ram@lemuria ~]$ ldd /lnx_data/apache2.0.54/modules/mod_dav_svn.so | grep apr
        libaprutil-1.so.0 => /lnx_data/apache2.0.54/lib/libaprutil-1.so.0 (0xb7def000)
        libapr-1.so.0 => /lnx_data/apache2.0.54/lib/libapr-1.so.0 (0xb7d59000)
[ram@lemuria ~]$ ldd /lnx_data/apache2.0.54/bin/httpd | grep apr
        libaprutil-1.so.0 => /lnx_data/apache2.0.54/lib/libaprutil-1.so.0 (0xb7f8f000)
        libapr-1.so.0 => /lnx_data/apache2.0.54/lib/libapr-1.so.0 (0xb7f6d000)

"mod_dav_svn.so" should be linked to the same APR libraries as used by "httpd", and fixing that took care of the problem.

Repository Access using HTTP

Following successful installation of Apache and Subversion, next, repository access via http:// schema must be configured in "</path/to/apache/conf>/httpd.conf". Some of the parameters that can be configured are related to hosting the repository; other parameters are related to the special/common user and group for Apache and Subversion:

# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.
#
# User/Group: The name (or #number) of the user/group to run httpd as.
# It is usually good practice to create a dedicated user and group for
# running httpd, as with most system services.
#
User apache
Group apache_svn

After creating the repository and configuration, it's time to bring-up the Web server and start accessing the repository via http:// schema. As you can see below, the "httpd" server is started and running as that special/common user, "apache":

[ram@lemuria ~]$ ps auxw | grep apache
root      2984  0.7  0.6   7616  2848 ?   Ss   19:46   0:00 /lnx_data/apache2.0.54/bin/httpd -k start
apache    2985  0.0  0.4   7616  1900 ?   S    19:46   0:00 /lnx_data/apache2.0.54/bin/httpd -k start
apache    2986  0.0  0.4   7616  1900 ?   S    19:46   0:00 /lnx_data/apache2.0.54/bin/httpd -k start
apache    2987  0.0  0.4   7616  1900 ?   S    19:46   0:00 /lnx_data/apache2.0.54/bin/httpd -k start
apache    2988  0.0  0.4   7616  1900 ?   S    19:46   0:00 /lnx_data/apache2.0.54/bin/httpd -k start
apache    2989  0.0  0.4   7616  1900 ?   S    19:46   0:00 /lnx_data/apache2.0.54/bin/httpd -k start

Configuring svnserve

As stated in the Subversion manual, the svnserve program is a lightweight server capable of communicating to clients over TCP/IP using a custom, stateful protocol. Clients can use svnserve services using either svn:// or svn+ssh:// access schema. However, before that, svnserve must be configured. Here, again, there are multiple options: svnserve can be configured to run by "inetd" or as a standalone daemon process.

Authentication Options

In the following examples I have configured two separate "svnserve" daemons, again on the same system, both serving different repositories and listening to different ports. For one of the repositories, authentication options are turned on using Subversion's built-in authentication and authorization mechanisms.

The result of configuring multiple repositories under "svnserve" is shown here.

Subversion's built-in authentication configured using "/path/to/repository/conf/svnserve.conf" is shown here.

The svnserve.conf shown in the previous example has many entries and one among them is password-db = passwd. This passwd file can be located in the same directory as "svnserve.conf" and sample entries of this file are shown here.

If "passwd-db = passwd" is turned on but there are no real entries in the "passwd" file, you'll see errors like this one:

[ram@lemuria svntest_project]$ svn commit -m "added the first test C file"
svn: Commit failed (details follow):
svn: /lnx_data/report_holder/svntest_project/conf/svnserve.conf:18: Section header expected

As can be seen here, commit operations will run successfully once the appropriate entries are defined in svnserve.conf and passwd.

NOTE: The passwd file referred to above is not the same as the system file, /etc/passwd. The system file cannot be used in svnserve's configuration.

Summary

In this brief article, I have tried to highlight basic parameters and options usable for configuring Subversion with or without Apache. It's also a good idea to go through Subversion documentation to clarify your doubts on this tool's usage. Many a time, it is worthwhile to consult people (e.g., the Subversion users mailing list) and seek guidance towards resolving Subversion problems.

[1] Rick Moen comments: Since all Linux Gazette editorial production is managed via svn (Subversion), we've tallied up considerable experience with both of these repository options over the years, and can heartily recommend the stability advantages of the newer FSFS option, which uses platform-independent flatfiles rather than database storage: Our experience with the older BerkeleyDB ("BDB") option was that improperly terminating svn processes would often wedge the repository if they died during commits, requiring an irksome "recovery" operation before work could resume. FSFS repositories are also less trouble to backup.

[2] Rick Moen comments: The usual cranky-sysadmin advice applies: In my view, as a matter of administrative best practices, compiling source code from an upstream maintainer's source tarball should be your last resort, if good official packages from your Linux distribution or trustworthy, quality unofficial packages constructed for your Linux distribution don't exist, only then should you use upstream tarballs as a fallback. Even then, check to see if the the tarball provides build instructions, e.g., an rpm SPEC file, for your distribution.

Why? Any time you skip the work done by distribution package maintainers and work directly with upstream source code, you're implicitly agreeing to either perform all of that work yourself or suffer the consequences of its absence. Most people have little conception of how much work that is, or its value. Package maintainers monitor upstream releases to select which have the best mix of new features and debugging (newer not necessarily being better), usually apply patches to adapt them to distribution-specific needs, and sometimes code and apply security patches the upstream programmer never even thought of. Moreover, they do this on an ongoing basis, making improvements available to a myriad of systems, keeping those systems updated without their admins needing to worry, let alone duplicate that work.

Talkback: Discuss this article with The Answer Gang

[BIO]

I hold an engineering degree in Electronics & Communication.

After finishing my degree in '95, I worked in customer support, system administration, and lab/tools administration in various start-ups and in Cisco's offshore development center in Chennai, India.

Currently, I am working at Infineon Tech India in the SCM (software config mgmt) domain, leading a team of 6 engineers specializing in IBM Rational ClearCase and ClearQuest with experience in Shell and Perl scripting.

Copyright © 2006, Muthaiah Ramanathan. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 128 of Linux Gazette, July 2006

<-- prev | next -->