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

Re: "svn commit" does not work with SVNParentPath in location and 1.7-client (HTTPv2)

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 17 Nov 2011 13:44:19 +0100

On Thu, Nov 17, 2011 at 11:50:20AM +0000, Philip Martin wrote:
> Stefan Sperling <stsp_at_elego.de> writes:
> > How do we avoid ambiguity when handling requests to nested Locations?
> > How can a client access a folder /bar inside a repository at Location /svn
> > if another repository exists at a nested Location /svn/bar?
> Yes, I was surprised too! If we assume that /svn and /svn/foo are
> directories that contain repositories then there can be no overlap:
> <Location /svn>
> ...
> SVNParentPath /svn
> </Location>
> <Location /svn/foo>
> ...
> SVNParentPath /svn/foo
> </Location>
> /svn/repo/<something> and /svn/foo/repo/<something> cannot overlap.
> The only way there could be a problem is if /svn/foo were itself a
> repository, but the admin can ensure that is not the case.

Yes, of course it works with SVNParentPath. But I suspect that is
a result of implementation rather than concious design.

Do we really want to encourage this practice?
It is very easy to make mistakes with this configuration.
And I don't see any advantage in nesting repositories like this.
What's the gain? To be frank, if the gain is to please cosmetic preferences
of some admins with respect to filesystem tree layout, I really don't
see why we should invest any effort on our part in supporting this.
Or is there a technical necessity for this setup which I'm overlooking?

In case we decide to fix mod_dav_svn to support this, would it be
possible to tell if overlapping Locations have been defined with SVNPath?
If so, mod_dav_svn should log a warning if it detects this situation.
A regression test should also be added if we decide to support this use case.
Received on 2011-11-17 13:44:54 CET

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.