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".
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.
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.
>> 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.
> 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.
--
Sergey Skvortsov
mailto: skv_at_protey.ru
Received on 2011-11-17 08:09:31 CET