[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Breaking large repository with lots of projects into chunks

From: Ryan Schmidt <subversion-2006d_at_ryandesign.com>
Date: 2006-10-28 22:45:22 CEST

On Oct 28, 2006, at 09:55, Tom H wrote:

>> The big issue (in my mind) of having 100s of repositories is that
>> it becomes a large administration headache (well, until you manage
>> to script everything). It can be more complex for the users as well.
>
> I am using mod_dav_svn as a front end, and the SVN authz file is
> automatically configured from a database, so I just as well script
> 100 <Location> directives into the httpd.conf file, as I can script
> the entries for repository paths in the SVN config file.
>
> However I am wondering whether there are any consequences for
> apache having 100 or more sets of Location directives;
>
> <Location /siteA>
> DAV svn
> SVNPath /usr/local/svn/siteA
> # our access control policy
> AuthzSVNAccessFile /path/to/access/file
> </Location>
>
> <Location /siteB>
> DAV svn
> SVNPath /usr/local/svn/siteB
> # our access control policy
> AuthzSVNAccessFile /path/to/access/file
> </Location>

Is there a reason you don't want to use the single directive

<Location />
  DAV svn
  SVNParentPath /usr/local/svn
  # our access control policy
  AuthzSVNAccessFile /path/to/access/file
</Location>

?

Note however that it is recommended to not put your SVNParentPath
at /; put it a level lower, like /svn/. This makes it easier to
handle files like favicon.ico, robots.txt and anything else that by
spec or convention must be at the root level.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Oct 28 22:46:17 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.