You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Sergey Skvortsov <sk...@protey.ru> on 2011/11/16 15:37:39 UTC
Re: "svn commit" does not work with SVNParentPath in location and
1.7-client (HTTPv2)
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?
It worked in 1.6 servers. It seems like regression.
> You need something like this instead:
>
> <Location /svn/bar>
> ...
> </Location>
>
> <Location /svn/foo>
> ...
> </Location>
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.
Please note that problem is only with "commit". Other commands work
just fine.
So I suppose it is bug.
--
Sergey Skvortsov
mailto: skv@protey.ru
Re: "svn commit" does not work with SVNParentPath in location and
1.7-client (HTTPv2)
Posted by Sergey Skvortsov <sk...@protey.ru>.
On 17.11.2011 11:40, David Chapman wrote:
> 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?
Please, re-read initial example.
"/svn/foo" is not a repo. It is just directory containing repos. And
"/svn" too.
You can not checkout "/svn/foo" or "/svn".
> 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.
Again, there are no nested repositories.
I am talking about broken SVNParentPath behaviour.
--
Sergey Skvortsov
mailto: skv@protey.ru
Re: "svn commit" does not work with SVNParentPath in location and
1.7-client (HTTPv2)
Posted by David Chapman <dc...@acm.org>.
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 dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Re: "svn commit" does not work with SVNParentPath in location and
1.7-client (HTTPv2)
Posted by Sergey Skvortsov <sk...@protey.ru>.
On 18.11.2011 17:14, Stefan Sperling wrote:
> On Thu, Nov 17, 2011 at 03:01:21PM +0100, Stefan Sperling wrote:
>> I can see your point but I don't think it's a very important issue.
>> If someone else wants to put in the effort into fixing this in mod_dav_svn
>> I won't object as long as the feature is properly implemented so people
>> don't shoot themselves in the foot when someone touches the configuration
>> (logging a warning is fine for this purpose).
>
> Sergey, FYI, Philip committed a fix that does the above. Bert Huijben and
> myself approved the fix so it will be included in Subversion 1.7.2.
Thanks for all participants!
--
Sergey Skvortsov
mailto: skv@protey.ru
Re: "svn commit" does not work with SVNParentPath in location and
1.7-client (HTTPv2)
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Nov 17, 2011 at 03:01:21PM +0100, Stefan Sperling wrote:
> I can see your point but I don't think it's a very important issue.
> If someone else wants to put in the effort into fixing this in mod_dav_svn
> I won't object as long as the feature is properly implemented so people
> don't shoot themselves in the foot when someone touches the configuration
> (logging a warning is fine for this purpose).
Sergey, FYI, Philip committed a fix that does the above. Bert Huijben and
myself approved the fix so it will be included in Subversion 1.7.2.
Re: "svn commit" does not work with SVNParentPath in location and
1.7-client (HTTPv2)
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Nov 17, 2011 at 05:39:37PM +0400, Sergey Skvortsov wrote:
> 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.
In your scheme, a more elaborate apache config has the required result:
<Location /svn/devops>
SVNPath /var/svn/devops
...
</Location>
<Location /svn/infra>
SVNPath /var/svn/infra
...
</Location>
<Location /svn/personal>
SVNParentPath /var/svn/personal
...
</Location>
> So, disabling this useful feature seems like ungrounded restriction for me.
Yes, because you want to use a single SVNParentPath directive to
serve your top-level repositories and you think having one Location
statement per top-level repository is too much of a burden to maintain.
I can see your point but I don't think it's a very important issue.
If someone else wants to put in the effort into fixing this in mod_dav_svn
I won't object as long as the feature is properly implemented so people
don't shoot themselves in the foot when someone touches the configuration
(logging a warning is fine for this purpose). And a regression test must
be added to make sure your configuration doesn't break again.
Re: "svn commit" does not work with SVNParentPath in location and 1.7-client (HTTPv2)
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 17, 2011, at 07:39, Sergey Skvortsov wrote:
> Do you really believe that normal admin is not smart enough to read docs?
Based on years of answering questions on this list: yes, sometimes. :)
Re: "svn commit" does not work with SVNParentPath in location and 1.7-client (HTTPv2)
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> I don't understand the "provided ..." bit. It seems to be flat out
> wrong.
Don't take that the wrong way: "It" refers to the code.
--
Philip
Re: "svn commit" does not work with SVNParentPath in location and 1.7-client (HTTPv2)
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@elego.de> writes:
> I agree that special-casing the root_dir seems unnecessary even in the
> mirroring case, provided that nested Locations are supposed to work.
I don't understand the "provided ..." bit. It seems to be flat out
wrong. If I fix the line then nested mirroring works when using
SVNParentPath, with 1.7 the commits fail even using the v1 protocol.
> Maybe this was done to guarantee consistent mirroring behaviour when
> Locations using SVNPath are nested accidentally? Even then, it seems
> bad to silently try to work around the problem instead of signaling
> a configuration error to the admin.
I don't understand how that would work.
--
Philip
Re: "svn commit" does not work with SVNParentPath in location and
1.7-client (HTTPv2)
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Nov 17, 2011 at 02:37:36PM +0000, Philip Martin wrote:
> The order of parent and child in Subversion's INHERIT_VALUE macro only
> has an effect when nesting one Subversion location in another. When not
> nested the parent root_dir is NULL and the child value will be used
> whatever the order in INHERIT_VALUE. I can't see how it would ever be
> correct to inherit the parent root_dir value.
I agree that special-casing the root_dir seems unnecessary even in the
mirroring case, provided that nested Locations are supposed to work.
Maybe this was done to guarantee consistent mirroring behaviour when
Locations using SVNPath are nested accidentally? Even then, it seems
bad to silently try to work around the problem instead of signaling
a configuration error to the admin.
> This bug only comes to light because 1.7 uses the root_dir value when
> processing POST requests; 1.6 doesn't use POST requests so the wrong
> value had no effect.
Right. That explains why Sergey's setup stopped working.
Re: "svn commit" does not work with SVNParentPath in location and 1.7-client (HTTPv2)
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@elego.de> writes:
> Yes, of course it works with SVNParentPath. But I suspect that is
> a result of implementation rather than concious design.
Perhaps, but the line that stops it working looks like an outright bug.
newconf->root_dir = INHERIT_VALUE(child, parent, root_dir);
The order of parent and child in Subversion's INHERIT_VALUE macro only
has an effect when nesting one Subversion location in another. When not
nested the parent root_dir is NULL and the child value will be used
whatever the order in INHERIT_VALUE. I can't see how it would ever be
correct to inherit the parent root_dir value.
This bug only comes to light because 1.7 uses the root_dir value when
processing POST requests; 1.6 doesn't use POST requests so the wrong
value had no effect.
--
Philip
Re: "svn commit" does not work with SVNParentPath in location and
1.7-client (HTTPv2)
Posted by Sergey Skvortsov <sk...@protey.ru>.
On 17.11.2011 16:44, Stefan Sperling wrote:
> On Thu, Nov 17, 2011 at 11:50:20AM +0000, Philip Martin wrote:
>> Stefan Sperling<st...@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: skv@protey.ru
Re: "svn commit" does not work with SVNParentPath in location and
1.7-client (HTTPv2)
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Nov 17, 2011 at 11:50:20AM +0000, Philip Martin wrote:
> Stefan Sperling <st...@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.
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?
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.
Re: "svn commit" does not work with SVNParentPath in location and 1.7-client (HTTPv2)
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@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.
--
Philip
Re: "svn commit" does not work with SVNParentPath in location and
1.7-client (HTTPv2)
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Nov 17, 2011 at 11:01:39AM +0000, Philip Martin wrote:
> [Adding dev]
>
> Philip Martin <ph...@wandisco.com> writes:
>
> > Sergey Skvortsov <sk...@protey.ru> writes:
> >
> >> 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.
> >
> > Yes, POST requests are handled differently. You should be able to work
> > around the problem by disabling the v2 protocol using:
> >
> > SVNAdvertiseV2Protocol off
>
> The config is nested Locations with SVNParentPath:
>
> <Location /svn>
> ...
> SVNParentPath /home/svn
> </Location>
>
> <Location /svn/foo>
> ...
> SVNParentPath /home/svn/foo
> </Location>
>
> This works apart from v2 commits to the nested Location. The reason it
> fails is that the POST gets directed to the containing Location, and
> that happens because of the root_dir setting in mod_dav_svn's dir_conf_t
> setup in mod_dav_svn.c:merge_dir_config:
>
> /* Prefer our parent's value over our new one - hence the swap. */
> newconf->root_dir = INHERIT_VALUE(parent, child, root_dir);
>
> All the other fields use INHERIT_VALUE(child, parent, ...).
>
> This code was added in the first commit to the dav-mirror branch and has
> not been changed since.
>
> If I change it to prefer the child value for root_dir then POSTs go to
> the right Location and commits work. Changing it doesn't break my
> simple mirror setup.
>
> I don't understand why the code prefers the parent root_dir. I can't
> think of any reason why mirroring would make a difference. Can anyone
> explain?
Do we really support nested Locations?
I was under the impression that this was never supported.
The book advises against using nesting Locations. The example given in
the book has two nested Locations, one of which is served by HTTPD itself
and one served by mod_dav_svn.
Is this really supposed to work if mod_dav_svn is serving both Locations?
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?
Re: "svn commit" does not work with SVNParentPath in location and 1.7-client (HTTPv2)
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> [Adding dev]
Gah! Got the address wrong. I'll start a thread on dev.
--
Philip
Re: "svn commit" does not work with SVNParentPath in location and 1.7-client (HTTPv2)
Posted by Philip Martin <ph...@wandisco.com>.
[Adding dev]
Philip Martin <ph...@wandisco.com> writes:
> Sergey Skvortsov <sk...@protey.ru> writes:
>
>> 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.
>
> Yes, POST requests are handled differently. You should be able to work
> around the problem by disabling the v2 protocol using:
>
> SVNAdvertiseV2Protocol off
The config is nested Locations with SVNParentPath:
<Location /svn>
...
SVNParentPath /home/svn
</Location>
<Location /svn/foo>
...
SVNParentPath /home/svn/foo
</Location>
This works apart from v2 commits to the nested Location. The reason it
fails is that the POST gets directed to the containing Location, and
that happens because of the root_dir setting in mod_dav_svn's dir_conf_t
setup in mod_dav_svn.c:merge_dir_config:
/* Prefer our parent's value over our new one - hence the swap. */
newconf->root_dir = INHERIT_VALUE(parent, child, root_dir);
All the other fields use INHERIT_VALUE(child, parent, ...).
This code was added in the first commit to the dav-mirror branch and has
not been changed since.
If I change it to prefer the child value for root_dir then POSTs go to
the right Location and commits work. Changing it doesn't break my
simple mirror setup.
I don't understand why the code prefers the parent root_dir. I can't
think of any reason why mirroring would make a difference. Can anyone
explain?
--
Philip
Re: "svn commit" does not work with SVNParentPath in location and 1.7-client (HTTPv2)
Posted by Philip Martin <ph...@wandisco.com>.
Sergey Skvortsov <sk...@protey.ru> writes:
> 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.
Yes, POST requests are handled differently. You should be able to work
around the problem by disabling the v2 protocol using:
SVNAdvertiseV2Protocol off
--
Philip
Re: "svn commit" does not work with SVNParentPath in location and
1.7-client (HTTPv2)
Posted by Sergey Skvortsov <sk...@protey.ru>.
On 17.11.2011 11:35, Cooke, Mark wrote:
>> -----Original Message-----
>> From: Sergey Skvortsov [mailto:skv@protey.ru]
>> Sent: 17 November 2011 07:09
>> Subject: Re: "svn commit" does not work with SVNParentPath in
>> location and 1.7-client (HTTPv2)
>
> <snip>
>
>>
>> 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.
>>
>
> You asked for help on this list. Stefan took the time to explain what is wrong with your configuration and why.
Frankly, I want to see full explanation for these questions:
- Why "checkout" / "update" work with my configuration, but "commit" not?
- Why this configuration worked on 1.6 but fails on 1.7? (With the same
Apache version).
Until I'll see adequate explanations I suppose that there are a
regression bug.
> Now you tell him he is wrong?
Nope. I said that I disagree.
I did non see enough strong arguments for his thesises.
> Are you an apache httpd developer?
No, but I know internals of Apache (and even wrote several modules). So
I know what I am talking about. Are you?
> If not, then I recommend you re-read Stefan's explanation, he does know what he is talking about.
Please, re-read my answer to Stefan.
--
Sergey Skvortsov
mailto: skv@protey.ru
RE: "svn commit" does not work with SVNParentPath in location and
1.7-client (HTTPv2)
Posted by "Cooke, Mark" <ma...@siemens.com>.
> -----Original Message-----
> From: Sergey Skvortsov [mailto:skv@protey.ru]
> Sent: 17 November 2011 07:09
> Subject: Re: "svn commit" does not work with SVNParentPath in
> location and 1.7-client (HTTPv2)
<snip>
>
> 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.
>
You asked for help on this list. Stefan took the time to explain what is wrong with your configuration and why.
Now you tell him he is wrong? Are you an apache httpd developer?
If not, then I recommend you re-read Stefan's explanation, he does know what he is talking about.
~ mark c
Re: "svn commit" does not work with SVNParentPath in location and
1.7-client (HTTPv2)
Posted by Sergey Skvortsov <sk...@protey.ru>.
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@protey.ru
Re: "svn commit" does not work with SVNParentPath in location and
1.7-client (HTTPv2)
Posted by Stefan Sperling <st...@elego.de>.
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.