You probably don't need to know anything at all about svndiff --- if previous instances of the bug are representative, then you're free to treat consider the svndiff stream an opaque binary data.
That is, previously what happened is that fsfs wrote A_1 A_2 B_1 B_2 C_1 C_1 C_2 D_1 D_2 E_1 E_2 On Sat, 14 May 2011 21:24 +0200, "Steinar Bang" <s...@dod.no> wrote: > >>>>> Steinar Bang <s...@dod.no>: > > >>>>> Steinar Bang <s...@dod.no>: > >>>>> Stefan Sperling <s...@elego.de>: > > >>> Try to locate boundaries of representations, which look as follows: > > >>> https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure > >>> A representation begins with a line containing either "PLAIN\n" or > >>> "DELTA\n" or "DELTA <rev> <offset> <length>\n", where <rev>, <offset>, > >>> and <length> give the location of the delta base of the representation > >>> and the amount of data it contains (not counting the header or > >>> trailer). If no base location is given for a delta, the base is the > >>> empty stream. After the initial line comes raw svndiff data, followed > >>> by a cosmetic trailer "ENDREP\n". > > >> `M-j 1916 RET', takes me here: > >> 00000770: 4e44 5245 500a 4445 4c54 410a 5356 4e01 NDREP.DELTA.SVN. > >> 00000780: 0000 8c0c 823d 8431 823b 8140 4c00 8844 .....=.1.;.@L..D > >> 00000790: 4ca8 404e 0048 8100 bf45 820d 9945 820d L.@N.H...E...E.. > >> ... > > > So... trying to interpret this with the description that Stefan gave, > > and that Daniel referred to. Here we have "DELTA\n" (the "0A" is "\n"), > > which begins a representation according to the above description. > > > But this is where I get a bit lost. > > Just analyzing a little bit further from the /subversion/notes/svndiff > description that Daniel mentioned. > > The first part after "DELTA\n" is "SVN" followed by a one byte format > version number, in this case 0x01. > > And then comes the hard part: > After the header come one or more windows, until the document ends. > (So the decoder must have external context indicating when there is no > more svndiff data.) > > Then comes the description of a window, and that is, as Daniel said, > probably not human readable, or even recognizable in a hex editor, > because the window may be zlib compressed (or so I understand it). > > Hm... hard this is. The dark side strong in this one. > >
