Setting up subversion (svn) repository: on mounted or network drive, using symbolic link (symlink), dynamically under SVNParentPath. Howto, what works and what fails.

By neokrates, written on July 3, 2011


  • Join date: 11-30-99
  • Posts: 224
View Counter:
Rate it
  • Which tool is used for SCM/VCS in your enterprise?

    View Results

    Loading ... Loading ...
  • bodytext bodytext bodytext

There are many ways to setup SVN repositories. server side SVN setup is expected to be scalable and flexible. Many storage devices available to satisfy such requirements: different hard drives, mounted external storage, NFS, NAS, SAN, etc. Here are some use cases which work, common problems, risks and errors.

You can save a lot of time and maybe many repositories and work hours of your teams if you know which ‘more complex’ repository setup can and will work, and which has a problem. In my experience, most combinations work, but putting repository on NAS, network or SAN may be a big mistake.
At least, until the svn 1.6 version it was risky.

I prefix all options with either WORKS: or FAILS: to underline the fact that such setup is ok or not ok.


WORKS: Dynamically add and remove repositories: use SVNParentPath

If you want new repositories without svn server restarts, here is a good way. Declare root with SVNParentPath.

Basic subversion.conf looks like:

<Location /svn/your_repos>
DAV svn
SVNParentPath /var/www/svn/your_repos

Then you can put new repos under /var/www/svn/your_repos.


Using symbolic link (symlink) for new repositories

You may have a multiple repositories declared under /var/www/svn/your_repos.
But now you also want one repository under /my/otherpath/repo1.
You can use softlink or mount to put this repo under /var/www/svn/your_repos!


Use chcon to set security context for SELinux

SELinux is a newer rights and groups management system for many Lynux distros like CentOS. Forgetting to set the security context might result in repository not accessible by svn process.

Note that if SELinux is enabled, the repositories must be labelled
with a context which httpd can write to; this will happen by default
for newly created directories in /var/www. Use the command
“restorecon -R /var/www/svn” to label the repositories if migrating
from a system without SELinux enabled; to label a repository outside
/var/www, use “chcon -R -h -t httpd_sys_content_t /path/to/repos”.

-part of default header comment of subversion.conf

So, do
chcon -R -h -u system_u -t httpd_sys_content_t /my/otherpath/repo1


WORKS: Use soft-link to put the repo under you repos root


cd /var/www/svn/your_repos
ln -s repo1 /my/otherpath/repo1

After that, repository should be brows-able under http://your.svn.server/svn/your_repos/repo1
(you access method may differ from http…)


WORKS: Or you may use mount --bind instead of soft-link


cd /var/www/svn/your_repos
mount --bind /my/otherpath/repo1 repo1

After that, repository should be brows-able under http://your.svn.server/svn/your_repos/repo1
(you access method may differ from http…)

on mounted or network drive


WORKS: Svn repository on mounted drive


WORKS: Multiple locations inside subversion.conf

First of all, you can have many repositories on many drives, using one Location per path. Having repositories on different physical drives inside the local file system is OK.

<Location /svn/your_repos>
DAV svn
SVNParentPath /var/www/svn/your_repos

<Location /svn/your_repos1>
DAV svn
SVNParentPath /my/otherpath

Just don’t forget to run chcon on all locations outside of /var/www/
Having symbolic links here is also perfectly ok. The disadvantage here is that you will need to restart Apache for new repositories to be loaded.


WORKS: Having soft-linked repo from another device under SVNParentPath

It is actually exactly the same as if you had your repository on the same device / drive, Just use chapter 2 to implement this method.


SVN repository on network drive

There are 2 types of filesystems, SVN repository can use: Berkley DB and FSFS.
Some years ago, there was one really good argument to use Berkley DB : it is established technology with long history, strong support, dedicated developer team.

But it has many disadvantages and now lots of projects have used FSFS for many years, so, basically, FSFS is a better choice in case of SVN.

To find out your repository’s FS, go to repository root and do : less db/fs-type.

It is important if you want to have SVN repository on network share (NAS, SAMBA etc…)
FSFS can be used on network share;
Berkley DB SVN repo can’t be used over network.

Here is a good comparison of this DB types.


FAILS: Having Berkley DB SVN repository on network drive

Don’t do this! It seems that there are limitations imposed by Berkley DB format used by subversion. The data may become corrupted or lost.

Do not create or access a Berkeley DB repository on a network share. It cannot exist on a remote file system. Not even if you have the network drive mapped to a drive letter. If you attempt to use Berkeley DB on a network share, the results are unpredictable – you may see mysterious errors right away, or it may be months before you discover that your repository database is subtly corrupted.



WORKS: Having FSFS SVN repository on network drive

Just make sure your repo is FSFS: less db/fs-type. This file system type can be used over network, with samba, etc..


Known problems & issues



Subversion may fail to see the repository. You get some sort of access error like:

Warning: Can't synchronize with the repository (Couldn't open Subversion repository //svn/repos: SubversionException: ("Can't open file '/home/svn/repos/format': Permission denied", 13)).


Could not open the requested SVN file system

You can try chcon command to fix it.

Also make sure svn user can see the repository, is owner, has correct permissions to read and write:

chown -R svnuser:svngroup /my/otherpath/repo1
chmod u+rw /my/otherpath/repo1


“Svn mirrored” setup and “Could not open the requested SVN filesystem”

If you have a mirror you will probably have a SVNMasterURI kind of directive on the slave host. It says, that all write actions should be propagated to the master.
So, to implement most of the solutions I described in this article, you will probably need to mirror the soft-linked or mounted setup. Otherwise you get a read-only repository.
I have never implemented such mirrored solution myself, so I don’t really know if it works or not.

Be Sociable, Share!

LEARN MORE (amazon bookstore)


Be Sociable, Share!

One Response to “Setting up subversion (svn) repository: on mounted or network drive, using symbolic link (symlink), dynamically under SVNParentPath. Howto, what works and what fails.”

  1. […] You are here: home  > learn > Article > Scm > Svn > Setting up subversion (svn) repository: on mounted or […]

Leave a Reply