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.

Article Comments:

Daniel Lucraft commented Fri Sep 07 11:13:04 UTC 2007:

Another great article!

I have a small suggestion: change

and adding this line:

#Allows svnserve connections from anywhere

-A INPUT -p tcp --dport 3690 -j ACCEPT

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

#Allows svnserve connections from anywhere

-A INPUT -p tcp --dport 3690 -j ACCEPT

On the other hand, you can argue that I now know more about iptables config and error logging than I did before ;-).

Daniel Lucraft commented Fri Sep 07 11:14:21 UTC 2007:

Markdown interpreted the comment symbol as "make this ludicrously big" in that last post. Hope it's still decipherable.

PickledOnion commented Fri Sep 07 11:37:58 UTC 2007:

Wow, that was big. Hope you don't mind but I changed it :)

Markdown interpreted the hash as an h1.

Anyway, thanks for the comment and good call.

PickledOnion.

Alexander Pranko commented Fri Dec 21 17:41:42 UTC 2007:

First of all many thanks to PickledOnion for the incredibly valuable and understandable articles. You can imagine how many m/h he saved for the users all over the world. It also looks like everyone likes SliceHost service and their philosophy. Me too :). Thank you, guys! It's really cool!

It looks like there is a typing error in the command lines for starting svnserve on a specific host and port. '-r' parameter should come right before the repository folder:

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

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

Alex Sharp commented Sun Feb 24 23:35:43 UTC 2008:

First, thanks for all your helpful articles. When I created my repository, my svnserve.conf and passwd files were in /home/demo/repository/[project_name]/conf/. The directory you specified did not exist. Was I supposed to create this directory/files, or is it not that big of a deal?

Fauzan commented Tue Sep 09 19:05:14 UTC 2008:

Once again, well done to PickledOnion for the easy-to-understand articles!

I would like to suggest, under the 'check out' section, to mention that we do the command from a new terminal and not from within the ssh terminal to the slicehost server.

Many thanks!

Fauzan

Vince commented Wed Oct 15 03:55:03 UTC 2008:

Thank you so much for a detailed article.

DiMi commented Wed Nov 19 08:49:35 UTC 2008:

Hi, First of all, thanks for great articles. Suggestion: it'd be great to know how to run svnserve as a service instead of a daemon. This link helped me: http://mohanjith.net/blog/2007/07/svnserve-init-script.html

David commented Fri Nov 28 01:14:07 UTC 2008:

Hi, First of all, Great articles. I'm getting an error when I run "svnserve -d -r /home/demo/repository" says "svnserve: Can't bind server socket: Address already in use"... Any idea? Thank you

Ben commented Sat Dec 20 20:11:42 UTC 2008:

just type "killall svnserve" and try again that will unbind the folder you binded it to.

Frank commented Sat Feb 07 10:55:32 UTC 2009:

I think there is an error in the svnserve syntax .... if you use

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

... it doesnt seem to work. You must put --listen-port as the second argument.

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

ahmad commented Wed Mar 04 13:32:46 UTC 2009:

i keep getting the error:

ahmad ~: svn co svn://67.23.7.131/project1 svn: Can't connect to host '67.23.7.131': Connection refused

i did the iptables stuff, any ideas?

Matt Huggins commented Thu Mar 26 01:14:28 UTC 2009:

It seems I need to specify port 3690 any time I want to check out. i.e. I need to do this:

svn co http://www.example.com:3690/project1/

...as opposed to simply doing this:

svn co http://www.example.com/project1/

Any suggestions?

Renier Pretorius commented Thu Apr 02 13:29:12 UTC 2009:

@Matt Huggins This is because you use the default port for svnserve. If you used any other port or apache, this would not work.

David Jacobs commented Thu Jun 18 19:49:42 UTC 2009:

I am having the same problem as ahmad, any help would be appreciated. Thanks.

Lauren commented Sun Jul 19 07:59:13 UTC 2009:

@ahmad and @David Jacobs:

Check the order of your firewall rules. As the article states, make sure the svn rule is

before any final LOG & REJECT rules

rupali commented Fri Jul 31 05:55:44 UTC 2009:

when i checkout using following command svn co svn://compaq/java /home/work it will ask me only first time username & password but 2nd time i run same command instead of /home/work i write /home/work1 it will not ask me username & password

venkat commented Wed Sep 02 11:56:59 UTC 2009:

sudo svn commit -m "directory added" --username harry Adding trunk/some svn: Commit failed (details follow): svn: Can't open file '/var/local/svn/myproject/db/txn-current-lock': Permission denied

How to resolve this problem

George L commented Wed Dec 30 21:34:09 UTC 2009:

In order for remote commits to work, the user that svnserve is running under, needs to have readwrite access to the repository database. For example, if I was logged in as user "foo" when I started svnserve, that user "foo" needs rw access to the database.

The way I did this was create a group "svn", add my user "foo" to it, set the group ownership on the entire repository to "svn", and allow the group to read/write on the entire repository.

venkat, this may explain your issue.

See

http://www.linuxfromscratch.org/blfs/view/svn/server/svnserver.html

for one way to handle this, although I didn't follow all the steps there yet. (I may need to follow it more closely down the line if I realize my permissions aren't working right still, especially its comments about umask 002.)