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