Introduction to svnserve

Following on from the Introduction to Subversion article, we'll now look at svnserve (subversion's built in server).

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

---

To check out 'project1' from a remote repository is very easy - it is usual to have the repository in a slice or other server and to work on the project (in this case project1) from a local machine such as your main workstation at home or work.

starting svnserve

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

svnserve -d -r /home/demo/repository

Short and sweet. Now we have svnserve allowing remote access to our repository on the default port of 3690.

iptables

If you have an iptables setup or other firewall, don't forget to allow connections to port 3690. This can be achieved by opening the iptables test file:

sudo nano /etc/iptables.test.rules

and adding this line before any final LOG & REJECT rules:

# Allows svnserve connections from anywhere
-A INPUT -p tcp --dport 3690 -j ACCEPT

Temporarily give yourself root access:

sudo -i

and activate the changes:

iptables-restore < /etc/iptables.test.rules

A quick check of the rules will show this extra line:

iptables -L
...
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:svn

Once happy, save the changes and exit out of the root access:

iptables-save > /etc/iptables.up.rules
...
exit

check out

Let's test it by checking out project1 (remember the IP address is for the slice containing the subversion repository:

svn co svn://123.45.67.890/project1

That was quick and easy to do.

svnserve permissions

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 it up (on the slice hosting the repository):

nano /home/demo/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/demo/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 (again, on the remote repository slice):

nano /home/demo/repository/conf/passwd

Enter authorised users along with their passwords:

[users]
project1admin = mypassword

remote commit

Let's make a small change to the project on our local workstation and, now that the permissions have been set on the remote repository, commit them:

mkdir goodbye
svn add goodbye
...
svn commit -m "Added goodbye folder" --username project1admin

Enter the password we set earlier and this is the result:

svn commit -m "Added goodbye folder" --username project1admin
Authentication realm: <svn://123.45.67.890:3690> Project1
Password for 'project1admin':
Adding         trunk/goodbye

Committed revision 4.

svnserve options

For more svnserve options, enter:

svnserve --help

Notice you can configure which port svnserve uses:

svnserve -d -r --listen-port 2122 /home/demo/repository

Or to respond to a single IP address only (my workstation IP for example):

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

Naturally that would only work if I had a static ip address.

autostarting svnserve

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

crontab -e

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

security

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

That's because it's not :)

We'll fix that in the next article by using the SSH protocol to connect to the repository.

PickledOnion.