On 11/16/2011 11:08 PM, Sergey Skvortsov wrote:
On 16.11.2011 19:56, Stefan Sperling wrote:
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?
Of course "/svn/foo".
Really? And what if you check out a copy of
http://svn.example.com/svn/foo and create a directory named "bar" in
it? Are you expecting Apache or Subversion to notice that this is the
path to another repository and thus ban creation of the new directory?
What if the repository http://svn.example.com/svn/foo already has a
directory named "bar" in it when you first move the child repository
into /svn/foo/bar?
I could go on, but the possibilities for ambiguity are endless. Don't
nest repositories.
Locations are worked down from shortest URI. So correct SVNParentPath
must be passed to mod_dav_svn.
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.
I disagree. This cite is irrelevant to my issue.
It worked in 1.6 servers. It seems like regression.
I am surprised that it worked.
I am not, because it's correct way.
It is not the correct way. Don't nest repositories.
Also, in 1.7 reading repos is working fine:
"OPTIONS /svn/foo/bar HTTP/1.1" 200
"REPORT /svn/foo/bar/!svn/me HTTP/1.1" 200
but only POST fails:
"POST /svn/foo/bar/!svn/me HTTP/1.1" 500
So the problem is not in Apache or configuration but in mod_dav_svn
itself.
It is obviously a regression.
It was never intended to work, so it cannot be a regression. Don't nest
repositories.
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.
I disagree, see above. There are robust way to handle <Location>s in
Apache.
I prefer to organize my repos in this way because is "natural".
Similar to filesystems: I like to place files and organize them to
folder/directories as I want to.
You are mixing file system references and Subversion references. This
leads to ambiguity. Don't do it, even if it feels natural to you.
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:
[skip]
This will give you a setup that works reliably.
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
