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 https://subversion.tigris.org/ This product includes software developed by CollabNet (https://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 https://subversion.tigris.org/ This product includes software developed by CollabNet (https://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 https://subversion.tigris.org/ This product includes software developed by CollabNet (https://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 https:// 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 https:// 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
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.
