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
