[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: Wed, 16 Nov 2011 16:56:12 +0100

On Wed, Nov 16, 2011 at 06:37:39PM +0400, Sergey Skvortsov wrote:
> s/"svn update"/"svn commit"/
>
> On 16.11.2011 18:31, Stefan Sperling wrote:
> >On Wed, Nov 16, 2011 at 02:43:17PM +0400, Sergey Skvortsov wrote:
> >>Configuration for Apache:
> >>
> >><Location /svn>
> >> DAV svn
> >> SVNParentPath /usr/home/svn
> >> SVNListParentPath on
> >></Location>
> >>
> >><Location /svn/foo>
> >> DAV svn
> >> SVNParentPath /usr/home/svn/foo
> >> SVNListParentPath on
> >></Location>
> >
> >>[Wed Nov 16 10:32:58 2011] [error] [client 10.10.10.10]
> >>(20014)Internal error: Can't open file
> >>'/usr/home/svn/foo/foo/format': No such file or directory
> >
> >You are nesting locations. This isn't a valid configuration because it
> >leads to ambiguity when splitting a URL into the part which is outside
> >of the repository and the part which is inside the repository.
>
> Why this configuration is not valid?

Before Subversion gets called, Apache HTTPD decides which Location
block gets to handle a request. Subversion has no control over this decision.
Note that Apache HTTPD looks only at URLs. It has no idea and does not care
whether or not there is a Subversion repository anywhere within the URL
http://svn.example.com/svn/foo/bar/baz
With your configuration the URL has two possible repositories:
http://svn.example.com/svn/foo
http://svn.example.com/svn/foo/bar
So how is Apache HTTPD supposed to tell which of your Location blocks
should handle requests for the URL http://svn.example/com/svn/foo/bar/baz?
Should <Location /svn> handle it or should <Location /svn/foo> handle it?

The documentation at http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.basic says:
======
Be sure that when you define your new Location, it doesn't overlap with other
exported locations. For example, if your main DocumentRoot is exported to /www,
do not export a Subversion repository in <Location /www/repos>. If a request
comes in for the URI /www/repos/foo.c, Apache won't know whether to look for a
file repos/foo.c in the DocumentRoot, or whether to delegate mod_dav_svn to
return foo.c from the Subversion repository. The result is often an error from
the server of the form 301 Moved Permanently.
======

The error you see is not 301 but the root cause of the problem is the same.

> It worked in 1.6 servers. It seems like regression.

I am surprised that it worked.

> I want to avoid use SVNPath for every leaf repo in the root.
> SVNParentPath is intended for such purpose.
>
> Also I want to use SVNListParentPath to autogenerate normal listing.
> It's impossible with multiple SVNPath.

You have repositories in /usr/home/svn and also /usr/home/svn/foo.
This is a bad way of organising your repositories because there is
no unique way to map URLs to repository roots.
Put your repositories into distinct, and flat, directories.
Don't nest them in a tree.

Move some of your repositories into /usr/home/svn/foo and some into
/usr/home/svn/bar, and change your configuration file to look like this:

<Location /svn/foo>
         DAV svn
         SVNParentPath /usr/home/svn/foo
         SVNListParentPath on
</Location>

<Location /svn/bar>
         DAV svn
         SVNParentPath /usr/home/svn/bar
         SVNListParentPath on
</Location>

This will give you a setup that works reliably.
Received on 2011-11-16 16:56:46 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.