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

Re: Organizing repositories.

From: Ryan Schmidt <subversion-2009b_at_ryandesign.com>
Date: Thu, 27 Aug 2009 07:33:25 -0500

On Aug 27, 2009, at 06:40, Jacobo García wrote:

> For each client I want to have a separated directory, and one svn
> repository for each project inside this client's directory.
>
> So let's say I have a client called 'wadus' and 2 projects for this
> client named 'foo' and 'bar'.
>
> mkdir -p /var/lib/svn/wadus
> svnadmin create /var/lib/svn/wadus/foo
> svnadmin create /var/lib/svn/wadus/bar
>
> I also want that if you go browse the main page of the repository lets
> say: http://svn.mycompany.com you can see a listing of all the clients
> (dirs) and browse up to the repositories as well.
>
> My third goal is to keep the configuration as much minimalistic as I
> can. It'd be perfect if i don't have to write any configuration when I
> have to add a new client to subversion. I haven't met this goal for
> the moment.

Yes, I don't believe it will be possible with today's Subversion.

> My first attempt is explained in the following configuration, this is
> the main svn apache virtualhost:
>
> <VirtualHost *>
> ServerName svn.mycompany.com
> ServerAlias *.svn.mycompany.com
> Include /etc/apache2/svn-clients/*
> LogLevel Debug
> ErrorLog /var/log/apache2/svn.err
> CustomLog /var/log/apache2/svn.log combined
> </VirtualHost>
>
> And inside /etc/apache2/svn-clients/ a file named 'wadus' after the
> client with the same name with the following config:
>
> <Location /wadus>
> DAV svn
> SVNParentPath /var/lib/svn/wadus/
> SVNListParentPath On
> AuthType Basic
> AuthName "Subversion Repository"
> AuthUserFile /etc/apache2/dav_svn.passwd
> Require valid-user
> </Location>
>
> Every client's directory will have a file like the one above.

I think that's about the best you can do today.

> The repositories both work in http and command line. But I can't get a
> listing of all the directories when trying to browse
> http://svn.mycompany.com ( I get an apache Not Found error, which
> makes sense). I tried to add a document root in the main svn config
> file but then I got the infamous 301 error (see
> http://subversion.tigris.org/faq.html#http-301-error) when checking
> out.

The VirtualHost *should* have a DocumentRoot, but having it be /var/
lib/svn would be a mistake. Make the document root be anywhere else
that will not overlap with your Subversion parent path.

> So, how can I make my repository browsable from the list of
> directories that contains the projects?

Write a script in PHP (or any other web scripting language of your
choice) to print out links for each client's directory. Put that PHP
script in the document root.

> Also, having a flat directory hierarchy (so I can use SVNParentPath
> and forget about everything) makes the repository harder to browse, so
> I think it's not smart at all. Is there any way to have a 2 level
> (clients/projects) hirerarchy with just one single apache config file?

It would be nice if SVNParentPath and SVNListParentPath would work
with an arbitrary hierarchy of directories. But currently they don't;
all repositories must be in a flat directory, as you've discovered.
So the best you can do is have multiple SVNParentPath /
SVNListParentPath directives, one for each directory you want
repositories to be inside.

An alternate strategy you could consider would be creating just one
repository for each client, and putting all that client's projects
into it. There are of course both pros and cons to this approach,
just like there are with the one you've tried already.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2387861

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-27 14:34:29 CEST

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.