Once you have all the necessary components installed on your
system, all that remains is the configuration of Apache via its
httpd.conf file. Instruct Apache to
load the mod_dav_svn module using
the LoadModule
directive. This directive must precede any other Subversion-related
configuration items. If your Apache was installed using the default
layout, your mod_dav_svn module
should have been installed in the modules subdirectory of the Apache install
location (often /usr/local/apache2). The LoadModule
directive has a simple syntax,
mapping a named module to the location of a shared library on
disk:
LoadModule dav_svn_module modules/mod_dav_svn.so
Note that if mod_dav was
compiled as a shared object (instead of statically linked directly to
the httpd binary), you’ll need a
similar LoadModule
statement for it,
too. Be sure that it comes before the mod_dav_svn line:
LoadModule dav_module modules/mod_dav.so LoadModule dav_svn_module modules/mod_dav_svn.so
At a later location in your configuration file, you now need to
tell Apache where you keep your Subversion repository (or repositories).
The Location
directive
has an XML-like notation, starting with an opening tag and ending with a
closing tag, with various other configuration directives in the middle.
The purpose of the Location
directive
is to instruct Apache to do something special when handling requests
that are directed at a given URL or one of its children. In the case of
Subversion, you want Apache to simply hand off support for URLs that
point at versioned resources to the DAV layer. You can instruct Apache
to delegate the handling of all URLs whose path portions (the part of
the URL that follows the server’s name and the optional port number)
begin with /repos/ to a DAV
provider whose repository is located at /var/svn/repository using the following
httpd.conf syntax:
<Location /repos> DAV svn SVNPath /var/svn/repository </Location>
If you plan to support multiple Subversion repositories that will
reside in the same parent directory on your local disk, you can use an
alternative directive—SVNParentPath
—to indicate that common parent directory. For example, if you know you
will be creating multiple Subversion repositories in a directory
/var/svn that would be accessed via
URLs such as http://my.server.com/svn/repos1
,
http://my.server.com/svn/repos2
, and so on, you could use the
httpd.conf configuration syntax in
the following example:
<Location /svn> DAV svn # any "/svn/foo" URL will map to a repository /var/svn/foo SVNParentPath /var/svn </Location>
Using the previous syntax, Apache will delegate the handling of
all URLs whose path portions begin with /svn/ to the Subversion DAV provider, which
will then assume that any items in the directory specified by the
SVNParentPath
directive are actually
Subversion repositories. This is a particularly convenient syntax in
that, unlike the use of the SVNPath
directive, you don’t have to restart Apache to create and network new
repositories.
Be sure that when you define your new Location
, it doesn’t overlap with other
exported locations. For example, if your main DocumentRoot
is exported to /www, do not export a Subversion repository
in <Location /www/repos>
. If a
request comes in for the URI /www/repos/foo.c, Apache won’t know
whether to look for a file repos/foo.c in the DocumentRoot
, or whether to delegate mod_dav_svn to return foo.c from the Subversion repository. The
result is often an error from the server of the form 301
Moved
Permanently
.
At this stage, you should strongly consider the question of permissions. If you’ve been running Apache for some time now as your regular web server, you probably already have a collection of content—web pages, scripts, and such. These items have already been configured with a set of permissions that allows them to work with Apache, or more appropriately, that allows Apache to work with those files. Apache, when used as a Subversion server, will also need the correct permissions to read and write to your Subversion repository.
You will need to determine a permission system setup that
satisfies Subversion’s requirements without messing up any previously
existing web page or script installations. This might mean changing the
permissions on your Subversion repository to match those in use by other
things that Apache serves for you, or it could mean using the User
and Group
directives in httpd.conf to specify that Apache should run
as the user and group that owns your Subversion repository. There is no
single correct way to set up your permissions, and each administrator
will have different reasons for doing things a certain way. Just be
aware that permission-related problems are perhaps the most common
oversight when configuring a Subversion repository for use with
Apache.