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
