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" <sb_at_dod.no> wrote:
> >>>>> Steinar Bang <sb_at_dod.no>:
>
> >>>>> Steinar Bang <sb_at_dod.no>:
> >>>>> Stefan Sperling <stsp_at_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.;._at_L..D
> >> 00000790: 4ca8 404e 0048 8100 bf45 820d 9945 820d L._at_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.
>
>
Received on 2011-05-14 21:47:37 CEST