Introduction to svnserve

You've created your subversion repository but now you don't want to check-out the latest version of your project on the same machine.

Subversion's svnserve allows you to access your project from remote machines. Concentrating on configuration and basic setup, this article introduces this often overlooked programme.

This follows directly from the Introduction to Subversion article and uses the same paths and project names.

Let's check out 'project1' from a remote place - this could be another VPS or server that you use for actual development or your main workstation at home.

We start the process by logging onto your VPS and starting svnserve. When issuing the svnserve command include the full path to your repository:

svnserve -d -r /home/paul/repository

Short and sweet. Now we have svnserve allowing remote access to our repository on the default port of 3690. If you have an iptables setup or other firewall, don't forget to allow connections to port 3690.

Let's test it by checking out project1. This should be done from a remote VPS or workstation:

svn co svn://123.45.67.890/project1

Naturally, you would use the IP address of the VPS where the subversion repository is located. I checked-out project1 from my home workstation:

That was quick and easy to do. We now have access to project1 which is great but try committing any changes and you will get an 'svn: Authorization failed' error.

Although good (we don't want everyone submitting changes to project1), we need read and write permissions to the repository.

svnserve has a very simple configuration file. Open that up:

nano /home/paul/repository/conf/svnserve.conf

The first thing you will notice is that everything is commented out. Let's delete all of that and start a simple configuration of our own.

# svnserve configuration

[general]

password-db = /home/paul/repository/conf/passwd

anon-access = read
auth-access = write

realm = Project1

I think the options are fairly self explanatory but do note that if you didn't want general access to the repository (i.e. it's not available to the public) you would change anon-access to:

anon-access = none

Next open the passwd file:

nano /home/paul/repository/conf/passwd

Enter authorised users along with their passwords:

[users]
project1admin = mypassword

When accessing the repository from our remote workstation nothing seems different until we try to commit any changes. Then we are asked for our username and password. Once entered, the changes are committed.

To avoid the annoyance of entering the username each time, you can enter this:

svn co svn://123.45.67.890/project1 --username project1admin

This will automatically use the username set in the passwd configuration file so all you have to do is enter the password.

For more svnserve options, enter:

svnserve --help

Notice you can configure which port svnserve uses and which IP address to listen to. So to only respond to my IP address I would enter:

svnserve -d -r --listen-host 123.45.67.890 /home/paul/repository

To make svnserve start on a reboot add the following to your crontab:

crontab -e

@reboot svnserve -d -r /home/paul/repository

As strangy points out, there are alternatives to starting svnserve on a reboot. He kindly points to this init script.

I am sure you will have noted that the connection to the subversion repository doesn't seem very secure. It's not.

We can fix that straight away by using the SSH protocol. Details can be found in the next article: Using SSH with svnserve.

PickledOnion.

Digg it | del.icio.us | reddit | StumbleUpon

Article Comments:

strangy 10 Jul, 2007

Insted of crontab you can use a real init script for Debian/Ubuntu found here

PickledOnion 10 Jul, 2007

Thanks strangy, I've put a link in the article as I think it's a useful script.

PickledOnion.

dirtymafia 13 Jul, 2007

xinetd is also very useful, that way it's not always running either.

Comments are closed for this article.