Setting Up Subversion for One or Multiple Projects

Deploying a secure and manageable Subversion installation that uses Apache 2.0 as a central authentication checkpoint and SSL for data integrity and confidentiality.
Per-Directory Configuration

In the configuration section I mentioned the module, created and installed by the Subversion installation process. This module allows us to define the access control policy on a directory basis, thus increasing the level of granularity.

Why do we need a separate module to take care of directory-based access control? Couldn't we use Apache configuration primitives? The problem here is the URL passed to Apache to access a repository, which is of the form:


As we can see, only the project path and name is visible: the project's accessed directory is hidden in the numeric code. Thus, we cannot directly apply Apache Location-based access control primitives. The solution consists of delegating directory access control to the module, which is able to parse the numeric code and identify the accessed directory.

The's access control policy is specified in a plain-text file with a simple syntax. Here's the one we use for our public projects (/svn/conf/policies/public_svn_authz):

foo = john, bob
bar = john, mike

* = r

@foo = rw

bob = r

john = r

@bar = rw

We first define the groups of users we want to specify the policy for, then we list the access control rules. The one under the [/] section specifies that any user can read the content of any project. For each project (for example [foo:/]) we specify a global access control policy, specifying it for the inner directories. There's no need to specify an access control rule for user john in the /branch/john directory, because it's inherited from the one in the upper-level directory.

In addition, we had to specify again the different groups' composition. We should avoid replication of such configuration directives as a good security practice. This problem is solved simply by removing any AuthGroupFile directive from the project configuration files and changing the related Require directive to a Require valid-user one, thus delegating group management to the module.

At this point all that remains is to add the directive AuthzSVNAccessFile to the default policy files in order to tell Apache that we intend to use the module as an access control facility. To do so, we must specify its configuration file. Here's the one for public projects:

<Location /public>
Dav svn

SVNParentPath /tmp/LJ/svn/repository/public

	Order deny,allow
	Deny from all
	Allow from

	Satisfy all

AuthzSVNAccessFile /tmp/LJ/svn/conf/public_svn_authz

<VirtualHost _default_:8081>
<Location /public>
Dav svn
SVNParentPath /tmp/LJ/svn/repository/public

Order allow,deny
Allow from all

       Order deny,allow
       Deny from all

       Satisfy all

AuthzSVNAccessFile /tmp/LJ/svn/conf/public_svn_authz

Include /tmp/LJ/svn/conf/policies/public/*


You may ask why we didn't use the module before. If we hadn't any trusted subnets, we could throw away most of the Apache access control machinery and rely solely on the, even if this is true only from Subversion 1.0.1. But because's access control strategy is user-based when in the scenario with a trusted subnet, we need a mix of source-based access control and user-based access control.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

VisualSVN Check out

Anonymous's picture

Hello All ... i really need help,
is there is any way to disable multiple checkouts in VisualSVN ?

which means when i'm checking out a file and working on it no one else can check it out ... as in Microsoft Visual Source Safe when someone try to check out a file that i'm currently worked in ... a message is displayed to the other user the me is working on this file and he cant access it.

your help will be much appreciated.

adding a new project to repository

Anonymous's picture

I like to know how to add a new project to repository. Can somebody pls help me. Your help will be highly appreciated.

502 Bad gateway error could

Mapk's picture

502 Bad gateway error could be solved by adding in your httpd.conf,

RequestHeader edit Destination ^https http early

5. Enable DAV to work with Apache running HTTP through SSL...

web based administration

Anonymous's picture

If you're after a simple approach that has a web-based administration on the top, you may want to check out Atlassian Crowd.


billie's picture

Getting the svn permissions just right for my security has been a real pain. Anyone else have good solutions to work with svn security?

Problem with per-directory

georgeen's picture

I read the svn-book, but isn´t clear the paths when the Subversion is on windows. Another thing is that in your article the users are defined into Apache but in svn-book them are defined into a plain text, at least as far as I undertood. Right now I have a problem because I don't know how to write the path of the directory inside svn_authz file (repo:c:/path...) or ( repo:/c:/path...) or (repo:c:\path...) or (repo:c/path... and variants). By the other hand when I use the Apache users file nobody can access, and message "FORBIDDEN You don't have permission to access..." appear, after the first try, but if is the plain text users file as svn-book then nobody can access but after three tries or pushing cancel button then the message "Authorization Required This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required." appear. Multiple paths on svnsecur were used with the same results if the Require valid-user is set. If I use only the Apache users file everything works fine, but isn't I need.

My configuration is:

svnusers.conf //this is the plain text user file

ehenao = pass_of_ehenao
oalvarez = pass_of_oalvarez
aperilla = pass_of_aperilla
marcelas = pass_of_marcelas
arodriguez = pass_of_marcelas
fcarrascal = pass_of_fcarrascal


developers = ehenao,oalvarez,aperilla,marcelas
document = arodriguez,fcarrascal
all = @developers,@document

@developers = rw

@document = rw
@developers = r

@todos = rw

and in httpd.conf

DAV svn
SVNParentPath C:\SVNRepositorio

AuthzSVNAccessFile C:\Archiv~1\Collab~1\httpd\conf\svnsecur.conf

AuthType Basic
AuthName "Repositorio PCT"
AuthUserFile C:\Archiv~1\Collab~1\httpd\conf\svnusers.conf
#AuthUserFile C:\Archiv~1\Collab~1\httpd\conf\svnusers.http.conf

Require valid-user

svnusers.http.conf is the file generated with htpasswd.

what I'm missing or overlooked?

MKACTIVITY - 403 Forbidden Error

Dinesh Pillay's picture


First off thanks for the great article. I followed the steps described and am able to see my repository and even checkout a test project from the same via HTTP.One difference here was that in public_default_policy.conf instead of "SVNParenPath /path/to/repo/public", I had to use "SVNPath /path/to/repo/public". Only then did I start seeing my projects.

Problems start when I try committing anything to that test project. I keep getting this particular error

svn: MKACTIVITY of '/public/!svn/act/505453b1-b22f-0410-b2eb-ca2e1334eb90': 403 Forbidden (http://localhost)

I see that you have printed a similar line in your article but the difference here is that for you it was "/public//svn..." but in my case it comes up as "/public/svn.." without the project name! Any ideas why that is happening?

Please let me know if you can find anything.

- Dinesh.

Just a correct.. its

Dinesh Pillay's picture

Just a correction.. its "public/_project_name_/svn.." the angle brackets were discarded by the engine.

- Dinesh.

Subversion Multi-Site

Elaine Murphy's picture

Interesting article - you should take a look at active/active replication for geographic distribution of Subversion -

Suggestion: mod_macro

Michael's picture

A nice thing to use for real complex setups with a lot of projects is mod_macro which we use over at the Subversion hosting service. It allows to re-use SVN configuration directives by simply adding a line like:
Use SVNRepositories Project1

Care to post it somewhere?

AnonymousR's picture

Care to post it somewhere?

Re: Setting Up Subversion for One or Multiple Projects

Anonymous's picture

First, I would like to say the article is very informative. However there are some inaccuracies (wrong paths, typos, missing paths) in the suggested configuration examples. It seems as though the author did not bother to actually test the configurations he suggests on a clean installation Linux with a default Apache 1.x installation; this is in-excusable.

I am running Slackware-current and I have setup the Apache 1.3.31 to ProxyPass to the Apache 2.0.50 server, as described in the article however I am having trouble with the Proxying.

I can do the following (at the local command prompt):
svn checkout http://localhost:8080/public/svn/myrepository/trunk

and it checks out fine.

However if I then do:
svn checkout

then I get the following error:
svn: PROPFIND request failed on '/public/myrepository/!svn/vcc/default'
svn: '/public/myrepository/!svn/vcc/default' path not found

Does anyone know if this is an issue with the proxying or maybe an issue with the svn client stripping '/svn/' on subsequent PROPFIND requests?

Here is my Proxy statements in my /etc/apache/httpd.conf file:
ProxyRequests Off
ProxyPass /svn/ http://localhost:8080/

Here is what I have configured in my /usr/local/svn/conf/public_default_policy.conf file:

Location /public
Dav svn
SVNParentPath /usr/local/svn/repository/public

same path to proxy

Anonymous's picture

To have proxy working properly you have to use the SAME path in both server.e.g.

ProxyPass /svn/ http://localhost:8080/svn/

VERY IMPORANT: same path to proxy

Anonymous's picture

If you wish to proxy all SVN/WebDAV requests correctly from Apache1 to Apache2, IT IS VERY IMPORTANT that the paths are the SAME in the ProxyPass, for example:

ProxyPass /svn/ http://localhost:8080/svn/

I spent 5h without any clue why I was getting PROPFIND error, and finally I made SVN to work behind a reverse proxy just by using the same path!!!!!

Re: Setting Up Subversion for One or Multiple Projects

Anonymous's picture

Just a wild guess, but don't you need a ProxyPassReverse in addition ?!?


Anonymous's picture

remember what you paid for the information ...

Remember what I paid for the

Lee's picture

Remember what I paid for the info? About as much as I paid for the OS! Dear-oh-deary me...

Re: in-excusable?

Anonymous's picture

If a computer technie writes a free tutorial with their real name and it is discovered that the tutorial is highly inaccurate, then only their reputation suffers for writing such garbage. Getting upset and posting you're disappointment is a good way to expose the incompetence of the writer of the tutorial. Just because the tutorial is free of charge does not protect the author from negative feedback from the readers.

Re: in-excusable?

Anonymous's picture

I hope you're not suggesting that visiting for information is a waste of time, because it contains information for free.

By the way, I found a solution to the issue.

Re: in-excusable?

Anonymous's picture

Btw I forgot to mention in my previous post that the proxies work through my web browers but are having the same issues as above in the svn checkout:

In browser: http://localhost/svn/proj1 correctly points to the Apache 2 server and my repository

svn co http://localhost/svn/proj1 proj1 produces the same error as above
svn co http://localhost:8800/proj1 proj1 works

Re: in-excusable?

Anonymous's picture

Can you please post a solution as I am having the same issues (with both http and https requests).

Also I have given up trying to use the public and private setup (all my repositories are now stored in /svn/repository/proj1 /svn/repository/proj2 etc.. and I have indiviudal conf files. This is because no matter what I tried the public/private directories kept getting a 403 forbidden error - anyone know the solution to this as well?

Re: Setting Up Subversion for One or Multiple Projects

Anonymous's picture

Nice tutorial, might have saved some time setting up our Subversion hosting service over at :)

svn: COPY of foo: 502 Bad Gateway ()

Anonymous's picture

Does anyone else experience this problem when trying to use tags and branches?

svn copy trunk/

svn: Commit failed (details follow):
svn: COPY of foo: 502 Bad Gateway (

svn: COPY of foo: 502 Bad Gateway ()

Jean-Pol Landrain's picture

Note: this can only happen with HTTPS

The explanation:
It seems there is no standard solution to this problem. Greg Stein has refused to implement a workaround in the Apache module: the problem happens because the hardware (reverse proxy, SSL accelerator or whatever decrypts the HTTPS) doesn't do correctly his job. It modifies the URL in the request but not in the "Destination" header of the DAV "COPY" requests (these DAV requests are issued from the SVN client when you do either a "copy" or "move"). Then when the svn server checks the parameters, it finds something incorrect. The position of Greg is understandable as it's not a problem caused by Apache or by SVN. The way we've fixed it here has required implementing a script inside the ssl accelerator, in order to also modify the "Destination" header in the DAV "COPY" requests to our SVN server. This solution works perfect, we've almost forgotten it's in place. If you can't do it in your reverse proxy, it's also possible to do it with a PERL script installed inside Apache (using mod_perl and the directives SetHandler and PerlHeaderParserHandler in the apache configuration file). If both these can't be done in your environment, your last resort will be to activate the ssl connection between the reverse proxy and Apache (but this wasn't possible here).

For reference:

One possible solution (using mod_perl):


Re: svn: COPY of foo: 502 Bad Gateway ()

Anonymous's picture

I think the problem is that Apache processes the proxy URL translation before it decrypts the HTTPS request. Since the to-URL of the COPY is in the encrypted body of the request, it never gets translated.

I haven't verified this but I'm pretty sure that's what's breaking you

Re: svn: COPY of foo: 502 Bad Gateway ()

Anonymous's picture

Oh, just found it:

"Name-based virtual hosting cannot be used with SSL secure servers because of the nature of the SSL protocol"

if you are using virtual host, then that is most likely what is causing it.

You can, but...

Brian C. Lane's picture

You can use SSL with named virtual hosts, but all of the clients connecting will get errors when checking the SSL certificate. All they need to do is ignore the errors (which you usually do for selfed CA certs anyway).


Re: svn: COPY of foo: 502 Bad Gateway ()

Anonymous's picture

I also get this problem.

I don't know what causes it but it seems to only happen with https and copying or moving (which is just a fancy copy) a file. It also use to work but then stopped, but I don't know what has changed in between.

Invalid command 'Proxy'

Anonymous's picture

For my Apache 1.3.31 "Proxy" is an unknown directive. Could you provide more information, how to enable this directive or do you meant the Redirect directive?

Proxy /svn/ http://localhost:8080/


Redirect /svn/ http://localhost:8080/

"Invalid command 'Proxy', perhaps mis-spelled or defined by a module not included in the server configuration"

Re: Invalid command 'Proxy'

Anonymous's picture

You have to make sure that proxy_module is loaded. Look for

LoadModule proxy_module /usr/lib/apache/1.3/

in the file /etc/apache/modules.conf

Look up your Apache-dokumentation for more information.

Regards, Bj

Re: Invalid command 'Proxy'

Anonymous's picture

Would you please check your documentation? There is no command Proxy!

Regards, Kai

Re: Invalid command 'Proxy'

rhpk's picture

It was a typing mistake. The correct Apache directive is:




Re: Setting Up Subversion for One or Multiple Projects

Anonymous's picture

Although this in itself is interesting, how about indicating which parts (to an apache newbie) are not relevant if you are working with a pure Apache 2 setup?

Re: Setting Up Subversion for One or Multiple Projects

rhpk's picture

Since all the information about athentication and access control is centralized in the Apache 2.0 server, the setup described in the article works as standalone too. The only change refers to SSL connections, which should be handled directly by Apache 2.0 through the SSL module.

Why two levels of apache?

happynut's picture

What was the reason for using two levels of apache?
It appears that the first apache just proxies everything
to the second.

Is it because you don't think apache 2.0 is secure enough
to be facing a public network? Or is there a subtler reason
that I'm just missing.

Re: Why two levels of apache?

Anonymous's picture

I'd expect it's because Apache 2.0's mod_ssl is not complete. It has an outstanding bug that prevents POST from working in conjunction with per directory/location SSL configuration. I've no idea how mod_ssl 2 would interact with DAV's other request types, either.

Re: Why two levels of apache?

Anonymous's picture

Mod SSL is fine with DAV requests - they're just http, after all.

Re: Why two levels of apache?

Anonymous's picture

Just a hunch as I'm still experimenting but I've found that trying to add the svn modules on top of an already working apache2 setup (PHP,SSL,mod_auth_mysql) just ends up being a mess that I can't get to work. I'm pretty well resigned to having to split up svn access, like this article, just to have mod_auth_mysql work in both environments.

Re: Why two levels of apache?

rhpk's picture

When compiled as an Apache module, Subversion requires Apache 2.0 while many production servers are based on the 1.3 series.

The migration from the 1.3 series to 2.0 series may not be the best choice for those installations: if you feel confident (from a security point-of-view) in your existing setup, you may not want to migrate to just enable Subversion.

If such situations, if you still want to use Subversion as an Apache module, the proxy solution is a good compromise.

Re: Why two levels of apache?

Anonymous's picture

Probably because most people with a public web server are already using Apache 1.3, and won't want to make more work for themselves by having to change that if it's working OK.

Very easy installation of apache subversion active directory

Anonymous's picture

Everyone is facing the problem of integration of apache/Subversion with Active directory. I found the document with complete package and it takes only 5-10 mins to install. You can also use the same and if any problem, Logon to, It is really very good.
Path is