On May 10, 2012, at 18:12 , Andreas Mohr wrote:
> Hi,
>
> subversion-1.6.17-1 here, on Linux RHEL5, versus a TFS SvnBridge server (don't think that matters though).
Hi Andreas,
that's an excellent bug report. Unfortunately, TFS SvnBridge isn't an
Apache Subversion server. It emulates the mod_dav_svn protocol,
like GitHub does.
http://svn.haxx.se/dev/archive-2012-02/0244.shtml
You'll have to contact the TFS SvnBridge developers.
Regards,
Steve
>
>
> ~/.subversion/servers:
> neon-debug-mask = 511
>
>
> .
> .
> .
> [chunk] < 400
> Got chunk size: 1024
> Reading 1024 bytes of response body.
> Got 1024 bytes.
> Read block (1024 bytes):
> [<S:set-prop name="svn:entry:last-author"></S:set-prop>
> <S:set-prop name="svn:entry:uuid">UUIDUUID-a1e8-4837-9fb9-UUIDUUIDUUID</S:set-prop>
> <S:prop></S:prop>
> </S:add-directory>
> <S:prop></S:prop>
> </S:add-directory>
> <S:prop></S:prop>
> </S:add-directory>
> <S:prop></S:prop>
> </S:add-directory>
> <S:prop></S:prop>
> </S:add-directory>
> <S:open-directory name="DIRNAME" rev="REVREV">
> <D:checked-in><D:href>/MY_TFS_SERVER:8080/!svn/ver/REVREV/PROJ/DIRNAME</D:href></D:checked-in>
> <S:set-prop name="svn:entry:committed-rev">REVREV</S:set-prop>
> <S:set-prop name="svn:entry:committed-date">2012-05-10T09:29:05.410000Z</S:set-prop>
> <S:set-prop name="svn:entry:last-author">unknown</S:set-prop>
> <S:set-prop name="svn:entry:uuid">UUIDUUID-a1e8-4837-9fb9-UUIDUUIDUUID</S:set-prop>
> <S:open-directory name="DIRNAME" rev="REVREV">
> <D:checked-in><D:href>/MY_TFS_SERVER:8080/!svn/ver/61677/PROJ/DIRNAME/DIRNAME</D:href></D:checked-in>
> <S:set-prop name="svn:entry:committed-rev">61677</S:set-prop>
> <S:set-prop name="svn:entry:committed-date">2012-05-1] <=======================
> XML: Parsing 1024 bytes. <=======================
> XML: start-element (224, {svn:, set-prop}) => 213
> XML: end-element (213, {svn:, set-prop})
> XML: char-data (224) returns 0
> XML: start-element (224, {svn:, set-prop}) => 213
> XML: char-data (213) returns 0
> XML: end-element (213, {svn:, set-prop})
> XML: char-data (224) returns 0
> XML: start-element (224, {svn:, prop}) => 245
> XML: end-element (245, {svn:, prop})
> XML: char-data (224) returns 0
> XML: end-element for 224 failed with -1.
> XML: end-element (224, {svn:, add-directory})
> XML: XML_Parse returned 1
> sess: Closing connection.
> sess: Connection closed.
> Request ends, status 200 class 2xx, error line:
> 200 OK
> Running destroy hooks.
> Request ends.
> svn: Bogus date <=======================
> sess: Destroying session.
> sess: Destroying session.
>
>
>
>
> To me it totally looks like svn proceeds with parsing the first chunk of the reply
> (a full initial 1024 bytes, as much as could be gathered within the
> statically-sized limited buffer),
> then the committed-date property manages to hit the end of the chunk
> (i.e., seemingly incomplete/corrupt content *within* this incomplete parsing context),
> thus date parsing throws a SVN_ERR_BAD_DATE somewhere,
> and this error state is actually taken at face value
> (read: a very large svn up operation simply aborted directly and fatally, ugh!)
> despite the chunk being an *INCOMPLETE* reply.
>
> ----> severe problem.
>
>
> (now that I reported it on users@, should I file this thing as a an actual honest-to-god bug?)
>
> Thanks,
>
> Andreas Mohr
--
Stephen Butler | Consultant
elego Software Solutions GmbH
Gustav-Meyer-Allee 25, 13355 Berlin, Germany
tel: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elego.de
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719
Received on 2012-05-10 18:32:40 CEST