On 17.11.2011 16:44, Stefan Sperling wrote:
On Thu, Nov 17, 2011 at 11:50:20AM +0000, Philip Martin wrote:
Stefan Sperling<s...@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.
How? Do you really believe that normal admin is not smart enough to read
docs?
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?
For example, our practice of layout organizing (simplified example):
/svn
/devops
/infra
/src
/personal
/user1
/user2
/project
/prj1
/prj2
/svn, /svn/personal, /svn/project are folders.
All the rest are repos.
/src contains common code, used by almost all projects.
/infra contains infrastructure stuff.
/devops contains devops code/scripts/data.
"user*" and "prj*" are especially made as separate repos by obvious reasons.
Maybe you would recommend to move "/src" to "/common/src" and "/infra"
to "/system/infra" and so on?
But short URIs are cool, and typing long one's is too tedious.
And naming such layout as "cosmetic preferences" is at least impolite.
So, disabling this useful feature seems like ungrounded restriction for me.
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.
--
Sergey Skvortsov
mailto: s...@protey.ru
