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.
