Skip to main content

Configuring Subversion (svn) on Linux (Debian Stable)

My last post documented how to install Subversion. This post will cover the resulting configuration of Apache, plus the creation of the initial repository.

When you install Subversion, it adds two LoadModule lines to /etc/apache2/httpd.conf. This is not wanted as the Debian version of Apache2 installs things slightly differently from the default Apache (httpd.conf is not used, all this configuration now lives in apache2.conf, plus the loading of modules is done differently). edit /etc/apache2/httpd.conf and remove the 2 uncommented LoadModule lines.

Debian loads modules a little differently that the default Apache2. It lists the available modules as individual configuration files within a mods-available directory, then enables these by linking to them from a mods-enabled directory.

We need to create the two required module configuration files that are required by Subversion (we just removed them from /etc/apache2/httpd.conf!):

cd /etc/apache2/mods-available
echo "LoadModule dav_svn_module /usr/lib/apache2/modules/" > dav_svn.load
echo "LoadModule authz_svn_module /usr/lib/apache2/modules/" > authz_svn.load

Now we need to enable them so that Apache will load them when it restarts:

cd ../mods-enabled
ln -s ../mods-available/dav.load
ln -s ../mods-available/dav_svn.load

That's the modules configured, now we need to create the Subversion virtual host entry that will point to our Subversion repository. Again, Debian does things a little different with virtual hosts, it has them listed as separate virtual host configuration files in sites-available and then enables them in sites-enabled:

cd /etc/apache2/sites-available

Due to Blogger being a pain when it comes to trying to post details containing lots of <'s and >'s, I'm including a link to an almost-copy of my Subversion virtual host configuration file. As you can see, it points the WebDAV & Subversion modules at /var/svn which will be the root of our repository, and uses Apache's htpasswd authentication to validate access.

Now we need to make the Subversion site available to Apache:

cd ../sites-enabled
ln -s ../sites-available/svn

Ok, that's Apache all done and dusted, now we just have to actually create the repository and then we are done.

The repository must be 'owned' by the same user that Apache runs as, otherwise read/write access may be blocked and all sorts of strange problems can occur, Debian runs Apache as user www-data by default:

mkdir /var/svn
chown www-data:www-data /var/svn

Now that the repository's root directory has been created, it's best to be the same user as Apache when creating the repository to ensure the files are created with the correct permissions:

su – www-data
svnadmin create /var/svn

That's the repository created, now we need to restart Apache to let the WebDAV & Subversion modules know that the repository is now available:

/etc/init.d/apache2 reload

If you now point your browser at you should see a web view of your new repository...what's that? It's asking for a username and password? Oh yes, we need to create any required users via the Apache htpasswd utility:

cd /etc/apache2
htpasswd -c svn.htpasswd your_username

Ok, try that URL again, you should be able to login and see a rather basic view of an empty Subversion repository. There is a slightly nicer skin that can be applied to Subversion to make the repository view cleaner, it's tucked away in the /usr/local/src/subversion-1.2.1/tools/xslt directory. These XSL and CSS files need to be added to the virtual host's document root, but as you may have noticed the DocumentRoot is the root of the Subversion repository. This means that you just have to import the two files into Subversion for the changes to take effect:

cd /usr/local/src/subversion-1.2.1/tools/xslt
svn import svnindex.xsl -m "Improved web interface."
svn import svnindex.css -m "Improved web interface."

Now revisit that URL again, and it should be a slightly nicer view of the repository, now with two files in it, svnindex.xsl and svnindex.css.

That's it, the repository is fully available to any user that you have created an htpasswd entry for in /etc/apache2/svn.htpasswd and who has a suitable Subversion client (TortoiseSVN and RapidSVN are two that I have used).

For full documentation on how to really use Subversion, please take a look at the O'Reilly Version Control with Subversion online book or buy the rather excellent book Pragmatic Version Control Using Subversion by Mike Mason.

Please let me know if you found this post (and the last one on how to install Subversion) useful, if so I might start to blog about Subversion even more...

UPDATE: I've moved some files around on my server, I've not changed any of the content of this post.

Technorati Tags: , , , ,


Anonymous said…
I've done SVN w/ WEB DAV before, but even if I hadn't, this walked me straight through it painlessly.

Everything still works fine with Subversion 1.3.1.
Andrew Beacock said…
Glad I could be of some help and thanks for letting me know that it works with the new version of Subversion.

I'll have to get my repository upgraded soon!
Anonymous said…
Great guide, however, when I attempt to restart apache I get the following error:

grep: /etc/apache2/sites-enabled/svn: no such file or directory

Any ideas?
Andrew Beacock said…
I'm not sure why it's not finding the svn file, Apache on Debian is setup to look for virtual hosts in the sites-enabled directory and so if it wasn't there then it shouldn't know to look for it!

Where is the "grep: " bit of the error coming from?
Anonymous said…
The reason of the error (/etc/apache2/sites-enabled/svn: no such file or directory) is that in the point "Due to Blogger being..." there was a link to a ready-made configuration, which was supposed to be saved as `/etc/apache2/sites-enabled/svn`.

Your guide was possible to copy-paste through besides this point.

I run up to the same problem, but solved it quickly, so I hope I'm in time to help the other anonymous.

And, thanks a lot for your guide, I got Subversion up and running very quickly with your help!

arttu dot manninen at protie dot fi
Anonymous said…
Hi Andrew,

your guide is great.
the only problem I encounter is thatI can't access the svn web interface.
This is the content of my /etc/apache2/sites-available/svn file:

(VirtualHost *)
ServerName svn.localhost.localdomain
ServerAlias svn.localhost

DocumentRoot /var/svn
ErrorLog /var/log/apache2/svn-error.log
CustomLog /var/log/apache2/svn-access.log combined

(Location /)
DAV svn
SVNPath /var/svn
SVNIndexXSLT "/svnindex.xsl"

AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/apache2/svn.htpasswd
Require valid-user

The apacpache server is running, so is SVN and DAV but I can't login to the web interface??
Andrew Beacock said…

Have you made the link from sites-enabled pointing to the svn file in sites-available?

What are you getting from Apache when you try to access your repository from a browser?
Andrew Beacock said…

Is your repository running at svn.localhost and is this hostname in your /etc/hosts file?

Is your repository at /var/svn?

Does apache report any problems when you perform a full restart?
Anonymous said…
hi anderw,

i've got it working now.
I just changed SVNPath to SVNParentPath end deleted the domain name, I just work with the ip now.

seems like i need to run a local domain server (bind) to accomplish this.

thx for your help and your great guide!
Casey said…
Andrew, thanks. These posts were a real help.
Anonymous said…
I will tryout now....
Raghu said…
Good one, it work well.

Thanks for posting and appreciate your work !

Anonymous said…
[ Due to Blogger being a pain when it comes to trying to post details containing lots of <'s and >'s, I'm including a link to an almost-copy of my Subversion virtual host configuration file. As you can see, it points the WebDAV & Subversion modules at /var/svn which will be the root of our repository, and uses Apache's htpasswd authentication to validate access.]
in above link, i haven't found the respective URL location, i mean there was no data available on that location........ so please let me response as soon as possible
Andrew Beacock said…

Sorry about that I've moved my hosted files around and forgot to update this blog post!
Anonymous said…
I've had problems with the additional XSLT and CSS files. It seems that dav_svn module serves all files as text/plain, so when I specify
SVNIndexXSLT /svnindex.xsl
Mozilla Firefox gives me the following error: "An XSLT stylesheet does not have an XML mimetype" as the .xsl and .css files are pulled from the SVN repository. Putting these files outside the SVN repository (on another vhost or in another Alias-ed directory solved the problem (svnindex.xsl is served with text/xslt now). I guess there are no such problems on IE due to its brain-dead magic filetype guessing.
Andrew Beacock said…
Hristo, that's strange as I also use Firefox (with both Windows and Ubuntu) to access my SVN repository and I've not had a problem.

I'll check my Apache configuration to see if I can find any clues, but if you find a solution then please post a comment with your findings.
Anonymous said…
Hellow Andrew,
I've found a solution or three to this problem. mod_mime has an option called ModMimeUsePathInfo which basically as far as I got it checks the full path of the request and sets the mime-type appropriately. This config option is by default set to 'off', so mod_mime doesn't consider the full path of the request, but gets only the part that is outside dav_svn's scope (i.e. the part outside the virtual tree, in you case it's '/' in my case it's '/svn/') and the request (and the mime-type returned) is then handled by mod_dav_svn. So setting this directive to on makes apache return mime-type out of its mime-type config instead of letting mod_dav_svn decide on it. This works for me and now accessing returns text/xslt instead of text/plain and Mozilla doesn't barf.
Another solution is setting svn:mime-type property inside your SVN repository, which will force mod_dav_svn to return the property value instead ot text/plain.
Another possibility is automapping:
You probably have one of these two set up in your SVN repo, so maybe that's the reason you don't have the same problem as I do.
Now honestly I don't have any idea of the impact of any of these two solutions as I am just a system administrator of the server in question. And since I'm not a programmer and am not using this repository I've got no idea of how this would impact usability.

Hope this helps.

Andrew Beacock said…
Hristo, you are a star! That is the most informative comment I have ever received!

Have you got your own blog? If not you should as you are extremely good at explaining things is a clear easy to understand manner! :)

Thanks for the solutions, I'm scratching my head now wondering if I set the mime-types properties direct or let SVN manage them for me.

It must have done it automatically as otherwise I would have blogged about it in the setup instructions.

Anyway thanks again for all the great information!
Anonymous said…
(It's so much easier using google when you know what you're looking for... ;-))
One more thing. mod_dav_svn has an option "SVNAutoversioning on" which, when combined with "ModMimeUsePathInfo on" might set svn:mime-type property based on mod_mime's logic on import.
(breaking the urls since blogger truncates them. Doh! don't you love it?)
Here are the three urls form my last comment:
Andrew Beacock said…
I'm looking at my server config now and I can't see any magic that I've setup. I've also run svn proplist on the two svnindex files and they have no properties attached.

I'll take a quick look in the mods-enabled to see if I have anything in there...
Andrew Beacock said…
Hristo, got it! In /etc/apache2/mods-enabled I have mime.conf (and mime.load) at the top of that file I have the follow:

# TypesConfig points to the file containing the list of mappings from
# filename extension to MIME-type.
TypesConfig /etc/mime.types

Within /etc/mime.types I have entries for CSS and XSL:

$ grep css mime.types
text/css css

$ grep xsl mime.types
application/xml xml xsl

So apache is using this file to determine the correct mime type to return in the HTTP header response.

Hope this helps!
Anonymous said…
thank you for your kind words! For me it's a way to give something back to the whole FOSS community. I'm glad that my explanations are clear and understandable even though English is not my native language. I must commend you on your howto as well. It's very precise and clear. I've had no problems following it. And, as you'll see in a second it's working perfectly well, despite my problems.
Here it goes: mod_mime is set up the same way on my server, it just doesn't kick in with my setup. Checking if mod_mime and /etc/mime.types is set up correctly was the first thing I checked yesterday. I even tried adding "AddType application/xml xsl" to my <Location> config but it simply didn't make any difference.
But I think I've finally found the culprit of the problem. It stems from the fact that your repository is set up as '/' on your server. In this case (and this is my wild guess after reading the doc of ModMimeUsePathInfo) mod_mime does it's job and gives the correct definition from /etc/mime.types. In my case though, my SVN repo is rooted in '/svn/' ( in which case, apparently, mod_mime doesn't kick in and leaves the mime-type determination to dav_svn.
I've set up another vhost with SVN rooted at '/' and it works the same way your setup does.

Anyway, mod_mime is one of the fundamental modules of apache, without it a lot of stuff wouldn't work as expected on standarts compliant and sane browsers (everything except IE? ;-)).

This entry starts looking like an IRC chat, isn't it? ;-))
Anonymous said…
Did you find out a solution?

Andrew Beacock said…
Alexey, I've not found out anything extra than what is posted above I'm afraid.
Thanks Hristo! Google brought me here and your comment gave me enough direction to find what I was looking for!

<Location /repos>
DAV svn
SVNPath /path/to/repos
ModMimeUsePathInfo On
Unknown said…
Hi Andrew,

Firstly thank you for creating a wonderful post on SVN. This has by far been the best tutorial on SVN.

I have installed SVN successfully and can also browse the repository using the browser... but the issue is that I am unable to import a file into the repository.

I get this error:

Error: Error while performing action: Can't open activity db. No such file or directory

Can you please help.

Would like to thank you again for creating a brilliant post.

Andrew Beacock said…
Sunil, I don't have a straight answer, but I do have some questions and ideas that might help:

* What tools/programs are you using to try and import or add the file? Standard SVN client via commandline or some other tool?

* When you run the import command are you doing it as the same user that installed subversion or as a normal user?

* Check the permissions of the installation around the area of the database files to ensure that they are accessible from your users.

* Have you installed the repository on a shared or mounted drive as this is not recommended:

Hope some or all of this helps! Keep me posted...
Unknown said…
Hi Andrew,

Thank you for helping out.

Ans1: I use the CLI and TortoiseSVN for import. For CLI I use this syntax:
/usr/local/subversion/bin/svn import svnindex.xsl -m "Improved web interface."

Ans2: I run it as root. But when I execute the same command from TortoiseSVN, I am logged in as the SVN user that I created in the htpasswd file.

Ans3: I have tried this as well. I am able to open files using the user pbsvn. I have created a user and group by the name of pbsvn and also make apache run as this user and group. However when I run the command ps aux | grep "httpd" it gives me the following output. Dont know how is the first thread running as 'root'

root 25596 0.0 0.4 18896 8744 ? Ss 18:35 0:00 /usr/sbin/httpd
pbsvn 25599 0.0 0.2 19280 5584 ? S 18:35 0:00 /usr/sbin/httpd
pbsvn 25600 0.0 0.2 19280 5476 ? S 18:35 0:00 /usr/sbin/httpd
pbsvn 25601 0.0 0.2 19280 5516 ? S 18:35 0:00 /usr/sbin/httpd
pbsvn 25602 0.0 0.2 19280 5576 ? S 18:35 0:00 /usr/sbin/httpd
pbsvn 25603 0.0 0.2 19280 5556 ? S 18:35 0:00 /usr/sbin/httpd
pbsvn 25604 0.0 0.2 19248 5508 ? S 18:35 0:00 /usr/sbin/httpd
pbsvn 25605 0.0 0.2 19280 5460 ? S 18:35 0:00 /usr/sbin/httpd
pbsvn 25606 0.0 0.2 19280 5496 ? S 18:35 0:00 /usr/sbin/httpd

Ans4: I have installed the repository on a Virtual Machine. As regards mounted drive, can you please help me understand how I can go about checking that.

Thanks again!

Andrew Beacock said…
It sounds to me like a permissions thing between the Apache user and the control permissions on the files and directories within the subversion repository.

Please check that all files and directories are owned by the same user or group that apache is running as, chown -R user:group *

Another thing to check is the WebDAV configuration to ensure that it really is looking in the correct place for the Subversion installation.

You mentioned virtual servers, do you have all of this running within one server or are you doing some cross-virtual server testing?

If all else fails try to add the files by placing them on the same host as the repos and adding them with the command line using a file:/// style URL:
Andrew Beacock said…
Sorry, it looks like blogger did't like the URL, here's another attempt:

file-based URL
Unknown said…
Hi Andrew,

I think I have solved this issue. All I did was use SVNParentPath as I wanted to create many sub repositories. In addition to this I also created a folder by the name of 'dav' (with user and group as that which runs apache).

Here is my httpd.conf listing. Hope its useful for someone else.

(VirtualHost *)
DocumentRoot /var/www/html
ErrorLog /var/log/apache2/svn-error.log
CustomLog /var/log/apache2/svn-access.log combined

(Location /svn)
DAV svn
SVNParentPath /var/svn

AuthType Basic
AuthName "Your Domain's Subversion Repository"
AuthUserFile /etc/apache2/svn.htpasswd
Require valid-user

Thanks again for all your help.

Andrew Beacock said…
Glad you got it sorted out! So just to clarify it was a problem with the locations that Apache though the repository was in?

Thanks for posting your solution and glad to be of whatever help I was!
Unknown said…
Hi Andrew,

The issue was:

a. Location / configuration of the repository

b. dav folder was missing inside my repository, which once created resolved the issue of uploading files.

Unknown said…
Hi Andrew,

When checking in the from windows or linux - I get this strange error:

Can't convert
>> string from native encoding to 'UTF-8'

I have tried everything from setting locale to en, en_US, en_US.iso885915

Can you please help me out.

Andrew Beacock said…
Suniil, what locale/language do you have set on your client machine?

What is the locale of the server?
Unknown said…
Hi Andrew,

Thank you for a quick reply.

Here is the output of the 'locale' command:


Andrew Beacock said…
Is this for the client or the server?
Unknown said…
This is for the server... I have tried various locales like en, en_US, and iso...

However, none of them work.

We use TortoiseSVN on Windows Machine.

Anonymous said…
Thank you very much for a such a helpful post. It saved me a lot of time.

mtju74 said…
Great post. thanks!