Subversion/Install

[edit] Introduction

Subversion is a version control software system, developed to be a replacement for CVS. It retains most of the syntax and the desirable features of CVS, while improving on its limitations.

Here we will discuss the setup of a working Subversion installation, allowing the user to access his files from SSH and HTTP. This implies the use of the svnserve server. We will also demonstrate how to manage a working copy of system configuration files in an SVN repository.

[edit] Installation

[edit] Preparation

Before you begin, you have to decide between two different data stores, Berkeley DB and FSFS (ordinary flat files). The Repository Administration chapter of Version Control with Subversion discuss the advantages and disadvantages of both data stores. By default, Gentoo chooses Berkeley DB as the datastore. You may opt to use FSFS instead by disabling as follows in /etc/portage/package.use:

 dev-vcs/subversion -berkdb

[edit] Changing repository location

Installation of subversion will place the repository at /var/svn. You can do the following before you emerge subversion if you want it placed somewhere else:

 # mkdir /path-to/repository-parent
 # ln -s /path-to/repository-parent /var/svn

[edit] Install

Now, you can install subversion depending on what your needs are.

[edit] Client-only Install

Just emerge as usual.

[edit] Server Install using Emerge

If you intend to run a Subversion server, a repository needs to be created. You can use the following command to create it in /var/svn:

This will also add the user svn and the group svnusers to your system.

[edit] Post-Installation

[edit] Fix the repository permissions

After the repository is created, the permissions need to be fixed.

Next, you should finally run

[edit] Give admin access to repository

Now you can give regular local users administrative access to the repositories by adding them to the group svnusers using

[edit] Server Setup

There are multiple ways to serve your repository.

[edit] svnserve daemon

• Configure /etc/conf.d/svnserve
• Start the server daemon with
  /etc/init.d/svnserve start
• Make it always start up at boot with
  rc-update add svnserve default

[edit] svnserve via xinetd

• edit /etc/xinetd.d/svnserve (remove disable line)

On my system the installed default /etc/xinetd.d/svnserve ran svnserve as user apache in group apache. If you used # emerge --config dev-util/subversion above or have otherwise created the user svn and the group svnusers then here's an alternative that might be more suitable for simple set-ups.

service svn
 {
 socket_type     = stream
 wait            = no
 user            = svn
 group           = svnusers
 umask           = 002
 protocol        = tcp
 log_on_failure += USERID HOST
 port            = 3690
 server          = /usr/bin/svnserve
 server_args     = -i -r /var/svn/repos
 disable         = no
 }

The -r option to the server is particularly nice because it simplifies your URLs (svn://host/) and prevents the server from straying outside the repository tree. If you have multiple repositories use -r /var/svn (or -r /path-to/reposparent) and the same server can give access to several independent repositories by passing it the appropriate name in the URL (svn://host/reposname).

• Reload xinetd with the command below.

• If you haven't already you might want to run the command below to start xinetd automatically at boot.

• You should also make sure the access restrictions in /etc/xinetd.conf are suitable for your site.

[edit] SVN over SSH

• create an svnserve wrapper in /usr/local/bin to set the umask you want, for example:

#!/bin/bash
. /etc/conf.d/svnserve
umask 002
exec /usr/bin/svnserve "$@"

• Run chmod a+x /usr/local/bin/svnserve as root.
• check that ssh yourhost "which svnserve" returns /usr/local/bin/svnserve and not /usr/bin/svnserve. If the latter is the case, SSH does not search /usr/local/bin for the svnserve command. To change that, you can use the PAM module pam_env.so which is usually included in /etc/pam.d/ssh via system-auth. pam_env's config file is /etc/security/pam_env.conf and by adding PATH OVERRIDE=/usr/local/bin:/usr/bin:/bin you instruct it to set this particular path for all system-auth services. It appears this PAM module affects local login commands also, so check you have all the directories normally included in root's PATH included in this /etc/security/pam_env.conf entry.

[edit] WebDAV

See Subversion/WebDAV

[edit] Troubleshooting

[edit] Moving a repository

If you do not want to symlink, or you have a populated repository in /var/svn that you want to move, simply run the following

which will relocate the home directory of user svn to /path-to/reposparent and copy the already created repos into it without messing up the permissions.

[edit] Updated Berkeley DB causes problems with Subversion

If you upgraded from an earlier version of berkely db and experience problems with your repository the run the following commands as root.