On 19 Aug 2011 at 19:20, Daniel Shahaf wrote:
> This asserts:
>
> $svn co http://svnbook.googlecode.com/svn/trunk/src/en/book@3805 && cd book && $svn up
>
Hi devs,
Just tried this on Windows with trunk.
Result:
Updating '.':
..\..\..\subversion\svn\update-cmd.c:163: (apr_err=175002)
..\..\..\subversion\libsvn_client\update.c:610: (apr_err=175002)
..\..\..\subversion\libsvn_client\update.c:551: (apr_err=175002)
..\..\..\subversion\libsvn_client\update.c:412: (apr_err=175002)
..\..\..\subversion\libsvn_ra_neon\fetch.c:2424: (apr_err=175002)
..\..\..\subversion\libsvn_ra_neon\fetch.c:2424: (apr_err=175002)
..\..\..\subversion\libsvn_ra_neon\util.c:1323: (apr_err=175002)
..\..\..\subversion\libsvn_ra_neon\util.c:660: (apr_err=175002)
svn: E175002: REPORT of '/svn/!svn/vcc/default': 200 OK (http://svnbook.googleco
de.com)
The response to the "REPORT" request is a chunked response of zero length.
I don't know if this is legal but sounds Ok to me.
This causes ne_discard_response() to return an error as it incorrectly
sees the "0" of the chunk length as a non zero length response.
I don't know enough about the neon library to dig further or suggest
a patch.
Regards
Alan
> This doesn't assert:
>
> $svn checkout -q http://svn-qavm.apache.org/repos/svnbook/trunk/src/en/book@3805 && cd book && $svn up
Received on 2011-08-21 12:40:22 CEST