You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Kylo Ginsberg <ky...@kylo.net> on 2010/01/04 16:36:32 UTC
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Self-bump and post to dev list also. Posting 2 days before Christmas
seems to be a bad way to get a response ... ;>
On Wed, Dec 23, 2009 at 1:13 PM, Kylo Ginsberg <ky...@kylo.net> wrote:
> Preparatory to setting up a proxy server, I'm trying to svnsync a
> repository from 1.6.6 server to another 1.6.6 server (both x86_64
> linux, one Fedora 7, one Fedora 12). Some user somehow managed to
> create a property "svn:" on a file and the svnsync fails like so:
>
> Transmitting file data .svnsync: At least one property change failed;
> repository is unchanged
> svnsync: PROPPATCH of
> '/svn-proxy-sync/!svn/wrk/82bb957d-3816-45ed-a262-dadb63d80787/users/jwhiteman/python/cfg/CFG.xml':
> 207 Multi-Status (http://hood)
>
> I'm able to reproduce (what I assume is) the same problem without svnsync:
> 1) create a repo, with both svn and http access methods
> 2) via svn access method create a file, set an "svn:" property, and
> commit it, e.g.
> svn co svn://snow/test test
> cd test/
> echo foo > foo.txt
> svn add foo.txt
> svn ps svn: asdf foo.txt
> svn ci -m testing
> 3) now try to access it via http:
>> svn pl http://snow/test/foo.txt
> svn: PROPFIND of '/test/!svn/bc/1/foo.txt': 207 Multi-Status (http://snow)
>
> So two questions here:
> 1) Is this a known issue? (I didn't see it in the bug db.) If not,
> can I get a second nomination that this is a bug? (If someone can
> point me in the right direction, and if this is likely to be a
> somewhat surgical fix, I'd be happy to attempt a patch.)
> 2) Any recommendations on how to proceed? For the initial sync of
> repos I can probably force the issue by svnsync'ing via the svn access
> method, but I don't think this will work once I set up write-through
> proxying.
>
> Thanks!
> Kylo
>
RE: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Engebakken Geir <ge...@edb.com>.
If someone is interested, this is what I found about cvs2svn problems generating this "207 Multi-status" return code.
http://old.nabble.com/bug-with---auto-props:-PROPFIND-pf...:-207-Multi-Status-td18510529.html
Geir
-----Original Message-----
From: Engebakken Geir [mailto:geir.engebakken@edb.com]
Sent: 5. januar 2010 14:21
To: C. Michael Pilato
Cc: Kylo Ginsberg; users@subversion.apache.org; dev@subversion.apache.org
Subject: RE: svnsync "207 Multi-Status" failure with http access method and property "svn:"
Right, but why doesn't the client handle this more "graciously", by examining the result and maybe point the user in a direction to find the cause of the "failure", instead of just spitting out "207 Multi-status"?
In our case we get this message diffing two revisions of a file, but we don’t know why it fails (although some time ago someone said something about cvs2svn not converting things correctly in all circumstances, leading to this error?).
Anyhow, the bottom line for me is that diffing these revisions still fails, and I don’t know why!
Geir
-----Original Message-----
From: C. Michael Pilato [mailto:cmpilato@collab.net]
Sent: 5. januar 2010 13:54
To: Engebakken Geir
Cc: Kylo Ginsberg; users@subversion.apache.org; dev@subversion.apache.org
Subject: Re: svnsync "207 Multi-Status" failure with http access method and property "svn:"
Engebakken Geir wrote:
> It seems to me that the 207 message is not an error message seen from
> Apache, rather an informative message, but that SVN interprets it as
> an error somehow. I would be glad to find out more about this ........
"207 Multi-Status" isn't an error at all. It's a code from Apache that means, "I've got multiple different pieces of status information to provide to you -- see the response body for details."
In Subversion, those multiple bits of status generally correspond to individual statii (heh) of property requests. Subversion says, "Apache, please send me properties 'foo', 'bar', and 'baz' on file.txt." But what if there's no 'bar' property on that file? Apache can't reply "200 OK", because all is not well. It can't reply "404 Item Not Found", because some of the items *were* found. So it replies "207 Multi-Status", and the body of the response contains the property values and 200 statuses for the requested properties that actually exist, plus 404 statuses for the properties that *don't* exist.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
RE: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Engebakken Geir <ge...@edb.com>.
Now you sound exactly as my boss sounds when I propose a fix somewhere :)
Not sure where to dive for the moment, we are mere users of SVN at the time being, but if this error prevails we might have to dig deeper. Thanks for the help though, great job you guys do!
Geir
-----Original Message-----
From: C. Michael Pilato [mailto:cmpilato@collab.net]
Sent: 5. januar 2010 14:54
To: Engebakken Geir
Cc: Kylo Ginsberg; users@subversion.apache.org; dev@subversion.apache.org
Subject: Re: svnsync "207 Multi-Status" failure with http access method and property "svn:"
Sure. Ideally, the client would be able to say, "I had trouble parsing the XML in the response, namely this bit here: <S:>asdf</S:>"
Wanna dive in and look into a patch?
Engebakken Geir wrote:
> Right, but why doesn't the client handle this more "graciously", by
> examining the result and maybe point the user in a direction to find
> the cause of the "failure", instead of just spitting out "207 Multi-status"?
>
> In our case we get this message diffing two revisions of a file, but
> we don’t know why it fails (although some time ago someone said
> something about cvs2svn not converting things correctly in all
> circumstances, leading to this error?).
>
> Anyhow, the bottom line for me is that diffing these revisions still
> fails, and I don’t know why!
>
>
> Geir
>
> -----Original Message----- From: C. Michael Pilato
> [mailto:cmpilato@collab.net] Sent: 5. januar 2010 13:54 To: Engebakken
> Geir Cc: Kylo Ginsberg; users@subversion.apache.org;
> dev@subversion.apache.org Subject: Re: svnsync "207 Multi-Status"
> failure with http access method and property "svn:"
>
> Engebakken Geir wrote:
>> It seems to me that the 207 message is not an error message seen from
>> Apache, rather an informative message, but that SVN interprets it as
>> an error somehow. I would be glad to find out more about this ........
>
> "207 Multi-Status" isn't an error at all. It's a code from Apache
> that means, "I've got multiple different pieces of status information
> to provide to you -- see the response body for details."
>
> In Subversion, those multiple bits of status generally correspond to
> individual statii (heh) of property requests. Subversion says,
> "Apache, please send me properties 'foo', 'bar', and 'baz' on
> file.txt." But what if there's no 'bar' property on that file?
> Apache can't reply "200 OK", because all is not well. It can't reply
> "404 Item Not Found", because some of the items *were* found. So it
> replies "207 Multi-Status", and the body of the response contains the
> property values and 200 statuses for the requested properties that
> actually exist, plus 404 statuses for the properties that *don't* exist.
>
> -- C. Michael Pilato <cm...@collab.net> CollabNet <>
> www.collab.net <> Distributed Development On Demand
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Andy Levy <an...@gmail.com>.
On Tue, Jan 5, 2010 at 11:28, Kylo Ginsberg <ky...@kylo.net> wrote:
> So one bug/enhancement here is to improve client reporting when it
> encounters a 207.
>
> But back to the root of my original problem: I can create a "svn:"
> property via the svn access method without any errors which then
> results in errors when accessed via the http access method. That
> seems like a bug, yes? But is the problem that the svn access method
> *allows* this bogus property, or that http chokes on it?
Flip a coin. One could make either argument about the root of the
problem. The bigger question is, if you code to prevent the bogus
property from being set, what will happen when you access a repository
via HTTP which already had those bogus properties set? You've stopped
people from setting them in the future, which is fine - but you still
have to handle the scenario where someone accesses the ones that were
previously set.
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Andy Levy <an...@gmail.com>.
On Tue, Jan 5, 2010 at 11:28, Kylo Ginsberg <ky...@kylo.net> wrote:
> So one bug/enhancement here is to improve client reporting when it
> encounters a 207.
>
> But back to the root of my original problem: I can create a "svn:"
> property via the svn access method without any errors which then
> results in errors when accessed via the http access method. That
> seems like a bug, yes? But is the problem that the svn access method
> *allows* this bogus property, or that http chokes on it?
Flip a coin. One could make either argument about the root of the
problem. The bigger question is, if you code to prevent the bogus
property from being set, what will happen when you access a repository
via HTTP which already had those bogus properties set? You've stopped
people from setting them in the future, which is fine - but you still
have to handle the scenario where someone accesses the ones that were
previously set.
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Kylo Ginsberg <ky...@kylo.net>.
On Tue, Jan 5, 2010 at 8:45 AM, C. Michael Pilato <cm...@collab.net> wrote:
> Kylo Ginsberg wrote:
>> But back to the root of my original problem: I can create a "svn:"
>> property via the svn access method without any errors which then
>> results in errors when accessed via the http access method. That
>> seems like a bug, yes? But is the problem that the svn access method
>> *allows* this bogus property, or that http chokes on it?
>
> That http chokes on it is a result of fact that we're trying to use WebDAV
> for these property interactions. PROPFINDs have a fixed response format
> which dictates that the property names be XML tags. That adds a whole layer
> of requirements for those names that technically Subversion itself doesn't
> itself need.
Ah, thanks, it's making more sense now. But are svn:xxx properties
handled via a different mechanism than other property namespaces? I
ask b/c experimentally I see that I can create or access a "foo:"
property via http just fine. So this problem is apparently entirely
restricted to the single case of an inadvertent "svn:" property?
> SIDEBAR: What happens if you set a property with a space in its name? Does
> the XML from mod_dav_svn have a tag like <S:property name>? If that doesn't
> fail, it would do worse: it could set a client-side property that doesn't
> actually exist in the repository "(property" instead of "property name").
# svn ps "svn:property name" asdf foo.txt
svn: 'svn:property name' is not a valid Subversion property name
I wonder if the spot where this validation is done could validate the
above case also?
> Anyway, it doesn't bother me that some RA layers allow things that others
> don't. I don't think the lowest common denominator is always a worthwhile
> goal, especially since most folks don't deploy Subversion over both svnserve
> and mod_dav_svn. We should document the differences, of course, and perhaps
> we can recommend a pre-commit hook script that is smart enough to check for
> all these kinds of potential gotchas.
If, as it appears, it's just "svn:" here, the pre-commit hook is pretty trivial.
> So I'd say it's a problem with http choking, and I say further that to the
> degree that we use WebDAV, we can expect this to keep happening. But
> perhaps the solution here is to ditch the PROPFINDs, though, and add a new
> custom REPORT request that's smart enough to deal with these issues. I
> mean, simply by moving the property names into CDATA, we'd gain alot more
> flexibility than we have today.
>
> The server can still support the PROPFINDs, of course, for compatability
> with older clients. Such compatibility means that either those PROPFINDs
> need to behave exactly as they do today, or they need to fail gracefully
> otherwise. But yes, they do need to fail -- we don't want a client getting
> incomplete data and thinking it's complete.
That all sounds pretty reasonable, but may be a heavyweight solution
given what (I now believe to be) the pretty limited scope of the
problem.
Thanks,
Kylo
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by "C. Michael Pilato" <cm...@collab.net>.
[dropping users@ -- we're well into dev-land here.]
Kylo Ginsberg wrote:
> So one bug/enhancement here is to improve client reporting when it
> encounters a 207.
>
> But back to the root of my original problem: I can create a "svn:"
> property via the svn access method without any errors which then
> results in errors when accessed via the http access method. That
> seems like a bug, yes? But is the problem that the svn access method
> *allows* this bogus property, or that http chokes on it?
That http chokes on it is a result of fact that we're trying to use WebDAV
for these property interactions. PROPFINDs have a fixed response format
which dictates that the property names be XML tags. That adds a whole layer
of requirements for those names that technically Subversion itself doesn't
itself need.
SIDEBAR: What happens if you set a property with a space in its name? Does
the XML from mod_dav_svn have a tag like <S:property name>? If that doesn't
fail, it would do worse: it could set a client-side property that doesn't
actually exist in the repository "(property" instead of "property name").
Anyway, it doesn't bother me that some RA layers allow things that others
don't. I don't think the lowest common denominator is always a worthwhile
goal, especially since most folks don't deploy Subversion over both svnserve
and mod_dav_svn. We should document the differences, of course, and perhaps
we can recommend a pre-commit hook script that is smart enough to check for
all these kinds of potential gotchas.
So I'd say it's a problem with http choking, and I say further that to the
degree that we use WebDAV, we can expect this to keep happening. But
perhaps the solution here is to ditch the PROPFINDs, though, and add a new
custom REPORT request that's smart enough to deal with these issues. I
mean, simply by moving the property names into CDATA, we'd gain alot more
flexibility than we have today.
The server can still support the PROPFINDs, of course, for compatability
with older clients. Such compatibility means that either those PROPFINDs
need to behave exactly as they do today, or they need to fail gracefully
otherwise. But yes, they do need to fail -- we don't want a client getting
incomplete data and thinking it's complete.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Kylo Ginsberg wrote on Tue, 5 Jan 2010 at 08:28 -0800:
> So one bug/enhancement here is to improve client reporting when it
> encounters a 207.
>
> But back to the root of my original problem: I can create a "svn:"
> property via the svn access method without any errors which then
> results in errors when accessed via the http access method. That
> seems like a bug, yes? But is the problem that the svn access method
> *allows* this bogus property, or that http chokes on it?
>
The latter. As far as libsvn_ra is concerned, property names can be any
UTF-8 string (values can be any byte string).
> I'd be willing to look into a patch if someone more knowledgeable
> agrees on what the bug is and can provide some pointers on where to
> start.
>
I don't know mod_dav_svn at all, so I'll let someone else answer here.
> Kylo
>
> On Tue, Jan 5, 2010 at 5:53 AM, C. Michael Pilato <cm...@collab.net> wrote:
> > Sure. Ideally, the client would be able to say, "I had trouble parsing the
> > XML in the response, namely this bit here: <S:>asdf</S:>"
> >
> > Wanna dive in and look into a patch?
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Kylo Ginsberg wrote on Tue, 5 Jan 2010 at 08:28 -0800:
> So one bug/enhancement here is to improve client reporting when it
> encounters a 207.
>
> But back to the root of my original problem: I can create a "svn:"
> property via the svn access method without any errors which then
> results in errors when accessed via the http access method. That
> seems like a bug, yes? But is the problem that the svn access method
> *allows* this bogus property, or that http chokes on it?
>
The latter. As far as libsvn_ra is concerned, property names can be any
UTF-8 string (values can be any byte string).
> I'd be willing to look into a patch if someone more knowledgeable
> agrees on what the bug is and can provide some pointers on where to
> start.
>
I don't know mod_dav_svn at all, so I'll let someone else answer here.
> Kylo
>
> On Tue, Jan 5, 2010 at 5:53 AM, C. Michael Pilato <cm...@collab.net> wrote:
> > Sure. Ideally, the client would be able to say, "I had trouble parsing the
> > XML in the response, namely this bit here: <S:>asdf</S:>"
> >
> > Wanna dive in and look into a patch?
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Kylo Ginsberg <ky...@kylo.net>.
So one bug/enhancement here is to improve client reporting when it
encounters a 207.
But back to the root of my original problem: I can create a "svn:"
property via the svn access method without any errors which then
results in errors when accessed via the http access method. That
seems like a bug, yes? But is the problem that the svn access method
*allows* this bogus property, or that http chokes on it?
I'd be willing to look into a patch if someone more knowledgeable
agrees on what the bug is and can provide some pointers on where to
start.
Kylo
On Tue, Jan 5, 2010 at 5:53 AM, C. Michael Pilato <cm...@collab.net> wrote:
> Sure. Ideally, the client would be able to say, "I had trouble parsing the
> XML in the response, namely this bit here: <S:>asdf</S:>"
>
> Wanna dive in and look into a patch?
>
> Engebakken Geir wrote:
>> Right, but why doesn't the client handle this more "graciously", by
>> examining the result and maybe point the user in a direction to find the
>> cause of the "failure", instead of just spitting out "207 Multi-status"?
>>
>> In our case we get this message diffing two revisions of a file, but we
>> don’t know why it fails (although some time ago someone said something
>> about cvs2svn not converting things correctly in all circumstances,
>> leading to this error?).
>>
>> Anyhow, the bottom line for me is that diffing these revisions still
>> fails, and I don’t know why!
>>
>>
>> Geir
>>
>> -----Original Message----- From: C. Michael Pilato
>> [mailto:cmpilato@collab.net] Sent: 5. januar 2010 13:54 To: Engebakken
>> Geir Cc: Kylo Ginsberg; users@subversion.apache.org;
>> dev@subversion.apache.org Subject: Re: svnsync "207 Multi-Status" failure
>> with http access method and property "svn:"
>>
>> Engebakken Geir wrote:
>>> It seems to me that the 207 message is not an error message seen from
>>> Apache, rather an informative message, but that SVN interprets it as
>>> an error somehow. I would be glad to find out more about this ........
>>
>> "207 Multi-Status" isn't an error at all. It's a code from Apache that
>> means, "I've got multiple different pieces of status information to
>> provide to you -- see the response body for details."
>>
>> In Subversion, those multiple bits of status generally correspond to
>> individual statii (heh) of property requests. Subversion says, "Apache,
>> please send me properties 'foo', 'bar', and 'baz' on file.txt." But what
>> if there's no 'bar' property on that file? Apache can't reply "200 OK",
>> because all is not well. It can't reply "404 Item Not Found", because
>> some of the items *were* found. So it replies "207 Multi-Status", and
>> the body of the response contains the property values and 200 statuses
>> for the requested properties that actually exist, plus 404 statuses for
>> the properties that *don't* exist.
>>
>> -- C. Michael Pilato <cm...@collab.net> CollabNet <>
>> www.collab.net <> Distributed Development On Demand
>>
>
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
RE: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Engebakken Geir <ge...@edb.com>.
Now you sound exactly as my boss sounds when I propose a fix somewhere :)
Not sure where to dive for the moment, we are mere users of SVN at the time being, but if this error prevails we might have to dig deeper. Thanks for the help though, great job you guys do!
Geir
-----Original Message-----
From: C. Michael Pilato [mailto:cmpilato@collab.net]
Sent: 5. januar 2010 14:54
To: Engebakken Geir
Cc: Kylo Ginsberg; users@subversion.apache.org; dev@subversion.apache.org
Subject: Re: svnsync "207 Multi-Status" failure with http access method and property "svn:"
Sure. Ideally, the client would be able to say, "I had trouble parsing the XML in the response, namely this bit here: <S:>asdf</S:>"
Wanna dive in and look into a patch?
Engebakken Geir wrote:
> Right, but why doesn't the client handle this more "graciously", by
> examining the result and maybe point the user in a direction to find
> the cause of the "failure", instead of just spitting out "207 Multi-status"?
>
> In our case we get this message diffing two revisions of a file, but
> we don’t know why it fails (although some time ago someone said
> something about cvs2svn not converting things correctly in all
> circumstances, leading to this error?).
>
> Anyhow, the bottom line for me is that diffing these revisions still
> fails, and I don’t know why!
>
>
> Geir
>
> -----Original Message----- From: C. Michael Pilato
> [mailto:cmpilato@collab.net] Sent: 5. januar 2010 13:54 To: Engebakken
> Geir Cc: Kylo Ginsberg; users@subversion.apache.org;
> dev@subversion.apache.org Subject: Re: svnsync "207 Multi-Status"
> failure with http access method and property "svn:"
>
> Engebakken Geir wrote:
>> It seems to me that the 207 message is not an error message seen from
>> Apache, rather an informative message, but that SVN interprets it as
>> an error somehow. I would be glad to find out more about this ........
>
> "207 Multi-Status" isn't an error at all. It's a code from Apache
> that means, "I've got multiple different pieces of status information
> to provide to you -- see the response body for details."
>
> In Subversion, those multiple bits of status generally correspond to
> individual statii (heh) of property requests. Subversion says,
> "Apache, please send me properties 'foo', 'bar', and 'baz' on
> file.txt." But what if there's no 'bar' property on that file?
> Apache can't reply "200 OK", because all is not well. It can't reply
> "404 Item Not Found", because some of the items *were* found. So it
> replies "207 Multi-Status", and the body of the response contains the
> property values and 200 statuses for the requested properties that
> actually exist, plus 404 statuses for the properties that *don't* exist.
>
> -- C. Michael Pilato <cm...@collab.net> CollabNet <>
> www.collab.net <> Distributed Development On Demand
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Branko Čibej <br...@xbc.nu>.
C. Michael Pilato wrote:
> Sure. Ideally, the client would be able to say, "I had trouble parsing the
> XML in the response, namely this bit here: <S:>asdf</S:>"
>
> Wanna dive in and look into a patch?
>
Actually .... the svn: in property names should never have been
interpreted as an XML namespace name in the DAV protocol mapping. Now we
have to live with that ...
-- Brane
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Branko Čibej <br...@xbc.nu>.
C. Michael Pilato wrote:
> Sure. Ideally, the client would be able to say, "I had trouble parsing the
> XML in the response, namely this bit here: <S:>asdf</S:>"
>
> Wanna dive in and look into a patch?
>
Actually .... the svn: in property names should never have been
interpreted as an XML namespace name in the DAV protocol mapping. Now we
have to live with that ...
-- Brane
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Kylo Ginsberg <ky...@kylo.net>.
So one bug/enhancement here is to improve client reporting when it
encounters a 207.
But back to the root of my original problem: I can create a "svn:"
property via the svn access method without any errors which then
results in errors when accessed via the http access method. That
seems like a bug, yes? But is the problem that the svn access method
*allows* this bogus property, or that http chokes on it?
I'd be willing to look into a patch if someone more knowledgeable
agrees on what the bug is and can provide some pointers on where to
start.
Kylo
On Tue, Jan 5, 2010 at 5:53 AM, C. Michael Pilato <cm...@collab.net> wrote:
> Sure. Ideally, the client would be able to say, "I had trouble parsing the
> XML in the response, namely this bit here: <S:>asdf</S:>"
>
> Wanna dive in and look into a patch?
>
> Engebakken Geir wrote:
>> Right, but why doesn't the client handle this more "graciously", by
>> examining the result and maybe point the user in a direction to find the
>> cause of the "failure", instead of just spitting out "207 Multi-status"?
>>
>> In our case we get this message diffing two revisions of a file, but we
>> don’t know why it fails (although some time ago someone said something
>> about cvs2svn not converting things correctly in all circumstances,
>> leading to this error?).
>>
>> Anyhow, the bottom line for me is that diffing these revisions still
>> fails, and I don’t know why!
>>
>>
>> Geir
>>
>> -----Original Message----- From: C. Michael Pilato
>> [mailto:cmpilato@collab.net] Sent: 5. januar 2010 13:54 To: Engebakken
>> Geir Cc: Kylo Ginsberg; users@subversion.apache.org;
>> dev@subversion.apache.org Subject: Re: svnsync "207 Multi-Status" failure
>> with http access method and property "svn:"
>>
>> Engebakken Geir wrote:
>>> It seems to me that the 207 message is not an error message seen from
>>> Apache, rather an informative message, but that SVN interprets it as
>>> an error somehow. I would be glad to find out more about this ........
>>
>> "207 Multi-Status" isn't an error at all. It's a code from Apache that
>> means, "I've got multiple different pieces of status information to
>> provide to you -- see the response body for details."
>>
>> In Subversion, those multiple bits of status generally correspond to
>> individual statii (heh) of property requests. Subversion says, "Apache,
>> please send me properties 'foo', 'bar', and 'baz' on file.txt." But what
>> if there's no 'bar' property on that file? Apache can't reply "200 OK",
>> because all is not well. It can't reply "404 Item Not Found", because
>> some of the items *were* found. So it replies "207 Multi-Status", and
>> the body of the response contains the property values and 200 statuses
>> for the requested properties that actually exist, plus 404 statuses for
>> the properties that *don't* exist.
>>
>> -- C. Michael Pilato <cm...@collab.net> CollabNet <>
>> www.collab.net <> Distributed Development On Demand
>>
>
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by "C. Michael Pilato" <cm...@collab.net>.
Sure. Ideally, the client would be able to say, "I had trouble parsing the
XML in the response, namely this bit here: <S:>asdf</S:>"
Wanna dive in and look into a patch?
Engebakken Geir wrote:
> Right, but why doesn't the client handle this more "graciously", by
> examining the result and maybe point the user in a direction to find the
> cause of the "failure", instead of just spitting out "207 Multi-status"?
>
> In our case we get this message diffing two revisions of a file, but we
> don’t know why it fails (although some time ago someone said something
> about cvs2svn not converting things correctly in all circumstances,
> leading to this error?).
>
> Anyhow, the bottom line for me is that diffing these revisions still
> fails, and I don’t know why!
>
>
> Geir
>
> -----Original Message----- From: C. Michael Pilato
> [mailto:cmpilato@collab.net] Sent: 5. januar 2010 13:54 To: Engebakken
> Geir Cc: Kylo Ginsberg; users@subversion.apache.org;
> dev@subversion.apache.org Subject: Re: svnsync "207 Multi-Status" failure
> with http access method and property "svn:"
>
> Engebakken Geir wrote:
>> It seems to me that the 207 message is not an error message seen from
>> Apache, rather an informative message, but that SVN interprets it as
>> an error somehow. I would be glad to find out more about this ........
>
> "207 Multi-Status" isn't an error at all. It's a code from Apache that
> means, "I've got multiple different pieces of status information to
> provide to you -- see the response body for details."
>
> In Subversion, those multiple bits of status generally correspond to
> individual statii (heh) of property requests. Subversion says, "Apache,
> please send me properties 'foo', 'bar', and 'baz' on file.txt." But what
> if there's no 'bar' property on that file? Apache can't reply "200 OK",
> because all is not well. It can't reply "404 Item Not Found", because
> some of the items *were* found. So it replies "207 Multi-Status", and
> the body of the response contains the property values and 200 statuses
> for the requested properties that actually exist, plus 404 statuses for
> the properties that *don't* exist.
>
> -- C. Michael Pilato <cm...@collab.net> CollabNet <>
> www.collab.net <> Distributed Development On Demand
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
RE: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Engebakken Geir <ge...@edb.com>.
If someone is interested, this is what I found about cvs2svn problems generating this "207 Multi-status" return code.
http://old.nabble.com/bug-with---auto-props:-PROPFIND-pf...:-207-Multi-Status-td18510529.html
Geir
-----Original Message-----
From: Engebakken Geir [mailto:geir.engebakken@edb.com]
Sent: 5. januar 2010 14:21
To: C. Michael Pilato
Cc: Kylo Ginsberg; users@subversion.apache.org; dev@subversion.apache.org
Subject: RE: svnsync "207 Multi-Status" failure with http access method and property "svn:"
Right, but why doesn't the client handle this more "graciously", by examining the result and maybe point the user in a direction to find the cause of the "failure", instead of just spitting out "207 Multi-status"?
In our case we get this message diffing two revisions of a file, but we don’t know why it fails (although some time ago someone said something about cvs2svn not converting things correctly in all circumstances, leading to this error?).
Anyhow, the bottom line for me is that diffing these revisions still fails, and I don’t know why!
Geir
-----Original Message-----
From: C. Michael Pilato [mailto:cmpilato@collab.net]
Sent: 5. januar 2010 13:54
To: Engebakken Geir
Cc: Kylo Ginsberg; users@subversion.apache.org; dev@subversion.apache.org
Subject: Re: svnsync "207 Multi-Status" failure with http access method and property "svn:"
Engebakken Geir wrote:
> It seems to me that the 207 message is not an error message seen from
> Apache, rather an informative message, but that SVN interprets it as
> an error somehow. I would be glad to find out more about this ........
"207 Multi-Status" isn't an error at all. It's a code from Apache that means, "I've got multiple different pieces of status information to provide to you -- see the response body for details."
In Subversion, those multiple bits of status generally correspond to individual statii (heh) of property requests. Subversion says, "Apache, please send me properties 'foo', 'bar', and 'baz' on file.txt." But what if there's no 'bar' property on that file? Apache can't reply "200 OK", because all is not well. It can't reply "404 Item Not Found", because some of the items *were* found. So it replies "207 Multi-Status", and the body of the response contains the property values and 200 statuses for the requested properties that actually exist, plus 404 statuses for the properties that *don't* exist.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by "C. Michael Pilato" <cm...@collab.net>.
Sure. Ideally, the client would be able to say, "I had trouble parsing the
XML in the response, namely this bit here: <S:>asdf</S:>"
Wanna dive in and look into a patch?
Engebakken Geir wrote:
> Right, but why doesn't the client handle this more "graciously", by
> examining the result and maybe point the user in a direction to find the
> cause of the "failure", instead of just spitting out "207 Multi-status"?
>
> In our case we get this message diffing two revisions of a file, but we
> don’t know why it fails (although some time ago someone said something
> about cvs2svn not converting things correctly in all circumstances,
> leading to this error?).
>
> Anyhow, the bottom line for me is that diffing these revisions still
> fails, and I don’t know why!
>
>
> Geir
>
> -----Original Message----- From: C. Michael Pilato
> [mailto:cmpilato@collab.net] Sent: 5. januar 2010 13:54 To: Engebakken
> Geir Cc: Kylo Ginsberg; users@subversion.apache.org;
> dev@subversion.apache.org Subject: Re: svnsync "207 Multi-Status" failure
> with http access method and property "svn:"
>
> Engebakken Geir wrote:
>> It seems to me that the 207 message is not an error message seen from
>> Apache, rather an informative message, but that SVN interprets it as
>> an error somehow. I would be glad to find out more about this ........
>
> "207 Multi-Status" isn't an error at all. It's a code from Apache that
> means, "I've got multiple different pieces of status information to
> provide to you -- see the response body for details."
>
> In Subversion, those multiple bits of status generally correspond to
> individual statii (heh) of property requests. Subversion says, "Apache,
> please send me properties 'foo', 'bar', and 'baz' on file.txt." But what
> if there's no 'bar' property on that file? Apache can't reply "200 OK",
> because all is not well. It can't reply "404 Item Not Found", because
> some of the items *were* found. So it replies "207 Multi-Status", and
> the body of the response contains the property values and 200 statuses
> for the requested properties that actually exist, plus 404 statuses for
> the properties that *don't* exist.
>
> -- C. Michael Pilato <cm...@collab.net> CollabNet <>
> www.collab.net <> Distributed Development On Demand
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
RE: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Engebakken Geir <ge...@edb.com>.
Right, but why doesn't the client handle this more "graciously", by examining the result and maybe point the user in a direction to find the cause of the "failure", instead of just spitting out "207 Multi-status"?
In our case we get this message diffing two revisions of a file, but we don’t know why it fails (although some time ago someone said something about cvs2svn not converting things correctly in all circumstances, leading to this error?).
Anyhow, the bottom line for me is that diffing these revisions still fails, and I don’t know why!
Geir
-----Original Message-----
From: C. Michael Pilato [mailto:cmpilato@collab.net]
Sent: 5. januar 2010 13:54
To: Engebakken Geir
Cc: Kylo Ginsberg; users@subversion.apache.org; dev@subversion.apache.org
Subject: Re: svnsync "207 Multi-Status" failure with http access method and property "svn:"
Engebakken Geir wrote:
> It seems to me that the 207 message is not an error message seen from
> Apache, rather an informative message, but that SVN interprets it as
> an error somehow. I would be glad to find out more about this ........
"207 Multi-Status" isn't an error at all. It's a code from Apache that means, "I've got multiple different pieces of status information to provide to you -- see the response body for details."
In Subversion, those multiple bits of status generally correspond to individual statii (heh) of property requests. Subversion says, "Apache, please send me properties 'foo', 'bar', and 'baz' on file.txt." But what if there's no 'bar' property on that file? Apache can't reply "200 OK", because all is not well. It can't reply "404 Item Not Found", because some of the items *were* found. So it replies "207 Multi-Status", and the body of the response contains the property values and 200 statuses for the requested properties that actually exist, plus 404 statuses for the properties that *don't* exist.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
RE: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Engebakken Geir <ge...@edb.com>.
Right, but why doesn't the client handle this more "graciously", by examining the result and maybe point the user in a direction to find the cause of the "failure", instead of just spitting out "207 Multi-status"?
In our case we get this message diffing two revisions of a file, but we don’t know why it fails (although some time ago someone said something about cvs2svn not converting things correctly in all circumstances, leading to this error?).
Anyhow, the bottom line for me is that diffing these revisions still fails, and I don’t know why!
Geir
-----Original Message-----
From: C. Michael Pilato [mailto:cmpilato@collab.net]
Sent: 5. januar 2010 13:54
To: Engebakken Geir
Cc: Kylo Ginsberg; users@subversion.apache.org; dev@subversion.apache.org
Subject: Re: svnsync "207 Multi-Status" failure with http access method and property "svn:"
Engebakken Geir wrote:
> It seems to me that the 207 message is not an error message seen from
> Apache, rather an informative message, but that SVN interprets it as
> an error somehow. I would be glad to find out more about this ........
"207 Multi-Status" isn't an error at all. It's a code from Apache that means, "I've got multiple different pieces of status information to provide to you -- see the response body for details."
In Subversion, those multiple bits of status generally correspond to individual statii (heh) of property requests. Subversion says, "Apache, please send me properties 'foo', 'bar', and 'baz' on file.txt." But what if there's no 'bar' property on that file? Apache can't reply "200 OK", because all is not well. It can't reply "404 Item Not Found", because some of the items *were* found. So it replies "207 Multi-Status", and the body of the response contains the property values and 200 statuses for the requested properties that actually exist, plus 404 statuses for the properties that *don't* exist.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by "C. Michael Pilato" <cm...@collab.net>.
Engebakken Geir wrote:
> It seems to me that the 207 message is not an error message seen from
> Apache, rather an informative message, but that SVN interprets it as an
> error somehow. I would be glad to find out more about this ........
"207 Multi-Status" isn't an error at all. It's a code from Apache that
means, "I've got multiple different pieces of status information to provide
to you -- see the response body for details."
In Subversion, those multiple bits of status generally correspond to
individual statii (heh) of property requests. Subversion says, "Apache,
please send me properties 'foo', 'bar', and 'baz' on file.txt." But what if
there's no 'bar' property on that file? Apache can't reply "200 OK",
because all is not well. It can't reply "404 Item Not Found", because some
of the items *were* found. So it replies "207 Multi-Status", and the body
of the response contains the property values and 200 statuses for the
requested properties that actually exist, plus 404 statuses for the
properties that *don't* exist.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by "C. Michael Pilato" <cm...@collab.net>.
Engebakken Geir wrote:
> It seems to me that the 207 message is not an error message seen from
> Apache, rather an informative message, but that SVN interprets it as an
> error somehow. I would be glad to find out more about this ........
"207 Multi-Status" isn't an error at all. It's a code from Apache that
means, "I've got multiple different pieces of status information to provide
to you -- see the response body for details."
In Subversion, those multiple bits of status generally correspond to
individual statii (heh) of property requests. Subversion says, "Apache,
please send me properties 'foo', 'bar', and 'baz' on file.txt." But what if
there's no 'bar' property on that file? Apache can't reply "200 OK",
because all is not well. It can't reply "404 Item Not Found", because some
of the items *were* found. So it replies "207 Multi-Status", and the body
of the response contains the property values and 200 statuses for the
requested properties that actually exist, plus 404 statuses for the
properties that *don't* exist.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
RE: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Engebakken Geir <ge...@edb.com>.
We have experienced the "207 Multi-status" error in subversion when diffing to revisions of a file. A search for a solution, and posting to the user list did not help us, so we still live with the problem that only has appeared for some files. It might have something to do with a SCM conversion utility that we have used, but we don't know.
It seems to me that the 207 message is not an error message seen from Apache, rather an informative message, but that SVN interprets it as an error somehow. I would be glad to find out more about this ........
Sorry for not being able to help out more ....
Geir
-----Original Message-----
From: kylo.ginsberg@gmail.com [mailto:kylo.ginsberg@gmail.com] On Behalf Of Kylo Ginsberg
Sent: 4. januar 2010 17:37
To: users@subversion.apache.org; dev@subversion.apache.org
Subject: Re: svnsync "207 Multi-Status" failure with http access method and property "svn:"
Self-bump and post to dev list also. Posting 2 days before Christmas
seems to be a bad way to get a response ... ;>
On Wed, Dec 23, 2009 at 1:13 PM, Kylo Ginsberg <ky...@kylo.net> wrote:
> Preparatory to setting up a proxy server, I'm trying to svnsync a
> repository from 1.6.6 server to another 1.6.6 server (both x86_64
> linux, one Fedora 7, one Fedora 12). Some user somehow managed to
> create a property "svn:" on a file and the svnsync fails like so:
>
> Transmitting file data .svnsync: At least one property change failed;
> repository is unchanged
> svnsync: PROPPATCH of
> '/svn-proxy-sync/!svn/wrk/82bb957d-3816-45ed-a262-dadb63d80787/users/jwhiteman/python/cfg/CFG.xml':
> 207 Multi-Status (http://hood)
>
> I'm able to reproduce (what I assume is) the same problem without svnsync:
> 1) create a repo, with both svn and http access methods
> 2) via svn access method create a file, set an "svn:" property, and
> commit it, e.g.
> svn co svn://snow/test test
> cd test/
> echo foo > foo.txt
> svn add foo.txt
> svn ps svn: asdf foo.txt
> svn ci -m testing
> 3) now try to access it via http:
>> svn pl http://snow/test/foo.txt
> svn: PROPFIND of '/test/!svn/bc/1/foo.txt': 207 Multi-Status (http://snow)
>
> So two questions here:
> 1) Is this a known issue? (I didn't see it in the bug db.) If not,
> can I get a second nomination that this is a bug? (If someone can
> point me in the right direction, and if this is likely to be a
> somewhat surgical fix, I'd be happy to attempt a patch.)
> 2) Any recommendations on how to proceed? For the initial sync of
> repos I can probably force the issue by svnsync'ing via the svn access
> method, but I don't think this will work once I set up write-through
> proxying.
>
> Thanks!
> Kylo
>
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
C. Michael Pilato wrote on Tue, 5 Jan 2010 at 00:32 -0500:
> Ben Collins-Sussman wrote:
> > Is svnserve really allowing you to create a random svn: junk property?
> > I was pretty sure that servers validated svn: properties -- only a
> > scant few exist, and users aren't supposed to be able to invent them.
> > My guess is that apache is throwing an error (207 mult-status probably
> > contains a 5XX code inside it somewhere) when it fails validate the
> > outgoing svn:asdf property, and then the svn client chokes on the
> > error.
>
> I'm pretty sure we do NOT have server validation of svn: property names. To
> date, most of our svn: properties are for client functionality only, so we
> would have been painting ourselves into a corner by having servers validate
> those suckers (forcing folks to upgrade servers just to get
> server-independent client functionality).
The server validates that the properties *it knows about* (e.g., svn:date,
svn:log) have valid values. Last I checked, we don't check either for
"unknown propname" svn:* props or for svn:* props used as versioned props
instead of revprops (or vice versa).
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
C. Michael Pilato wrote on Tue, 5 Jan 2010 at 00:32 -0500:
> Ben Collins-Sussman wrote:
> > Is svnserve really allowing you to create a random svn: junk property?
> > I was pretty sure that servers validated svn: properties -- only a
> > scant few exist, and users aren't supposed to be able to invent them.
> > My guess is that apache is throwing an error (207 mult-status probably
> > contains a 5XX code inside it somewhere) when it fails validate the
> > outgoing svn:asdf property, and then the svn client chokes on the
> > error.
>
> I'm pretty sure we do NOT have server validation of svn: property names. To
> date, most of our svn: properties are for client functionality only, so we
> would have been painting ourselves into a corner by having servers validate
> those suckers (forcing folks to upgrade servers just to get
> server-independent client functionality).
The server validates that the properties *it knows about* (e.g., svn:date,
svn:log) have valid values. Last I checked, we don't check either for
"unknown propname" svn:* props or for svn:* props used as versioned props
instead of revprops (or vice versa).
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman wrote:
> Is svnserve really allowing you to create a random svn: junk property?
> I was pretty sure that servers validated svn: properties -- only a
> scant few exist, and users aren't supposed to be able to invent them.
> My guess is that apache is throwing an error (207 mult-status probably
> contains a 5XX code inside it somewhere) when it fails validate the
> outgoing svn:asdf property, and then the svn client chokes on the
> error.
I'm pretty sure we do NOT have server validation of svn: property names. To
date, most of our svn: properties are for client functionality only, so we
would have been painting ourselves into a corner by having servers validate
those suckers (forcing folks to upgrade servers just to get
server-independent client functionality).
Also, Ben, you read Kylo's mail incorrectly. He didn't create an "svn:asdf"
property. He created an "svn:" property with value "asdf". So *my* guess
is that when mod_dav_svn is converting repository property names (such as
"svn:keywords") into PROPFIND response XML tags (such as "<S:keywords>"),
this "svn:" property is causing an essentially nameless tag ("<S:>") to be
generated and transmitted, which causes the client's XML parser to croak.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman wrote:
> Is svnserve really allowing you to create a random svn: junk property?
> I was pretty sure that servers validated svn: properties -- only a
> scant few exist, and users aren't supposed to be able to invent them.
> My guess is that apache is throwing an error (207 mult-status probably
> contains a 5XX code inside it somewhere) when it fails validate the
> outgoing svn:asdf property, and then the svn client chokes on the
> error.
I'm pretty sure we do NOT have server validation of svn: property names. To
date, most of our svn: properties are for client functionality only, so we
would have been painting ourselves into a corner by having servers validate
those suckers (forcing folks to upgrade servers just to get
server-independent client functionality).
Also, Ben, you read Kylo's mail incorrectly. He didn't create an "svn:asdf"
property. He created an "svn:" property with value "asdf". So *my* guess
is that when mod_dav_svn is converting repository property names (such as
"svn:keywords") into PROPFIND response XML tags (such as "<S:keywords>"),
this "svn:" property is causing an essentially nameless tag ("<S:>") to be
generated and transmitted, which causes the client's XML parser to croak.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Is svnserve really allowing you to create a random svn: junk property?
I was pretty sure that servers validated svn: properties -- only a
scant few exist, and users aren't supposed to be able to invent them.
My guess is that apache is throwing an error (207 mult-status probably
contains a 5XX code inside it somewhere) when it fails validate the
outgoing svn:asdf property, and then the svn client chokes on the
error.
On Mon, Jan 4, 2010 at 10:36 AM, Kylo Ginsberg <ky...@kylo.net> wrote:
> Self-bump and post to dev list also. Posting 2 days before Christmas
> seems to be a bad way to get a response ... ;>
>
> On Wed, Dec 23, 2009 at 1:13 PM, Kylo Ginsberg <ky...@kylo.net> wrote:
>> Preparatory to setting up a proxy server, I'm trying to svnsync a
>> repository from 1.6.6 server to another 1.6.6 server (both x86_64
>> linux, one Fedora 7, one Fedora 12). Some user somehow managed to
>> create a property "svn:" on a file and the svnsync fails like so:
>>
>> Transmitting file data .svnsync: At least one property change failed;
>> repository is unchanged
>> svnsync: PROPPATCH of
>> '/svn-proxy-sync/!svn/wrk/82bb957d-3816-45ed-a262-dadb63d80787/users/jwhiteman/python/cfg/CFG.xml':
>> 207 Multi-Status (http://hood)
>>
>> I'm able to reproduce (what I assume is) the same problem without svnsync:
>> 1) create a repo, with both svn and http access methods
>> 2) via svn access method create a file, set an "svn:" property, and
>> commit it, e.g.
>> svn co svn://snow/test test
>> cd test/
>> echo foo > foo.txt
>> svn add foo.txt
>> svn ps svn: asdf foo.txt
>> svn ci -m testing
>> 3) now try to access it via http:
>>> svn pl http://snow/test/foo.txt
>> svn: PROPFIND of '/test/!svn/bc/1/foo.txt': 207 Multi-Status (http://snow)
>>
>> So two questions here:
>> 1) Is this a known issue? (I didn't see it in the bug db.) If not,
>> can I get a second nomination that this is a bug? (If someone can
>> point me in the right direction, and if this is likely to be a
>> somewhat surgical fix, I'd be happy to attempt a patch.)
>> 2) Any recommendations on how to proceed? For the initial sync of
>> repos I can probably force the issue by svnsync'ing via the svn access
>> method, but I don't think this will work once I set up write-through
>> proxying.
>>
>> Thanks!
>> Kylo
>>
>
RE: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Engebakken Geir <ge...@edb.com>.
We have experienced the "207 Multi-status" error in subversion when diffing to revisions of a file. A search for a solution, and posting to the user list did not help us, so we still live with the problem that only has appeared for some files. It might have something to do with a SCM conversion utility that we have used, but we don't know.
It seems to me that the 207 message is not an error message seen from Apache, rather an informative message, but that SVN interprets it as an error somehow. I would be glad to find out more about this ........
Sorry for not being able to help out more ....
Geir
-----Original Message-----
From: kylo.ginsberg@gmail.com [mailto:kylo.ginsberg@gmail.com] On Behalf Of Kylo Ginsberg
Sent: 4. januar 2010 17:37
To: users@subversion.apache.org; dev@subversion.apache.org
Subject: Re: svnsync "207 Multi-Status" failure with http access method and property "svn:"
Self-bump and post to dev list also. Posting 2 days before Christmas
seems to be a bad way to get a response ... ;>
On Wed, Dec 23, 2009 at 1:13 PM, Kylo Ginsberg <ky...@kylo.net> wrote:
> Preparatory to setting up a proxy server, I'm trying to svnsync a
> repository from 1.6.6 server to another 1.6.6 server (both x86_64
> linux, one Fedora 7, one Fedora 12). Some user somehow managed to
> create a property "svn:" on a file and the svnsync fails like so:
>
> Transmitting file data .svnsync: At least one property change failed;
> repository is unchanged
> svnsync: PROPPATCH of
> '/svn-proxy-sync/!svn/wrk/82bb957d-3816-45ed-a262-dadb63d80787/users/jwhiteman/python/cfg/CFG.xml':
> 207 Multi-Status (http://hood)
>
> I'm able to reproduce (what I assume is) the same problem without svnsync:
> 1) create a repo, with both svn and http access methods
> 2) via svn access method create a file, set an "svn:" property, and
> commit it, e.g.
> svn co svn://snow/test test
> cd test/
> echo foo > foo.txt
> svn add foo.txt
> svn ps svn: asdf foo.txt
> svn ci -m testing
> 3) now try to access it via http:
>> svn pl http://snow/test/foo.txt
> svn: PROPFIND of '/test/!svn/bc/1/foo.txt': 207 Multi-Status (http://snow)
>
> So two questions here:
> 1) Is this a known issue? (I didn't see it in the bug db.) If not,
> can I get a second nomination that this is a bug? (If someone can
> point me in the right direction, and if this is likely to be a
> somewhat surgical fix, I'd be happy to attempt a patch.)
> 2) Any recommendations on how to proceed? For the initial sync of
> repos I can probably force the issue by svnsync'ing via the svn access
> method, but I don't think this will work once I set up write-through
> proxying.
>
> Thanks!
> Kylo
>
Re: svnsync "207 Multi-Status" failure with http access method and
property "svn:"
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Is svnserve really allowing you to create a random svn: junk property?
I was pretty sure that servers validated svn: properties -- only a
scant few exist, and users aren't supposed to be able to invent them.
My guess is that apache is throwing an error (207 mult-status probably
contains a 5XX code inside it somewhere) when it fails validate the
outgoing svn:asdf property, and then the svn client chokes on the
error.
On Mon, Jan 4, 2010 at 10:36 AM, Kylo Ginsberg <ky...@kylo.net> wrote:
> Self-bump and post to dev list also. Posting 2 days before Christmas
> seems to be a bad way to get a response ... ;>
>
> On Wed, Dec 23, 2009 at 1:13 PM, Kylo Ginsberg <ky...@kylo.net> wrote:
>> Preparatory to setting up a proxy server, I'm trying to svnsync a
>> repository from 1.6.6 server to another 1.6.6 server (both x86_64
>> linux, one Fedora 7, one Fedora 12). Some user somehow managed to
>> create a property "svn:" on a file and the svnsync fails like so:
>>
>> Transmitting file data .svnsync: At least one property change failed;
>> repository is unchanged
>> svnsync: PROPPATCH of
>> '/svn-proxy-sync/!svn/wrk/82bb957d-3816-45ed-a262-dadb63d80787/users/jwhiteman/python/cfg/CFG.xml':
>> 207 Multi-Status (http://hood)
>>
>> I'm able to reproduce (what I assume is) the same problem without svnsync:
>> 1) create a repo, with both svn and http access methods
>> 2) via svn access method create a file, set an "svn:" property, and
>> commit it, e.g.
>> svn co svn://snow/test test
>> cd test/
>> echo foo > foo.txt
>> svn add foo.txt
>> svn ps svn: asdf foo.txt
>> svn ci -m testing
>> 3) now try to access it via http:
>>> svn pl http://snow/test/foo.txt
>> svn: PROPFIND of '/test/!svn/bc/1/foo.txt': 207 Multi-Status (http://snow)
>>
>> So two questions here:
>> 1) Is this a known issue? (I didn't see it in the bug db.) If not,
>> can I get a second nomination that this is a bug? (If someone can
>> point me in the right direction, and if this is likely to be a
>> somewhat surgical fix, I'd be happy to attempt a patch.)
>> 2) Any recommendations on how to proceed? For the initial sync of
>> repos I can probably force the issue by svnsync'ing via the svn access
>> method, but I don't think this will work once I set up write-through
>> proxying.
>>
>> Thanks!
>> Kylo
>>
>