On Sat, 14 May 2011 22:46 +0300, "Daniel Shahaf" <danielsh_at_apache.org> wrote:
> 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
>
instead of the correct
A_1 A_2 B_1 B_2 C_1 C_2 D_1 D_2 E_1 E_2
where again A_i,B_i don't stand for anything in particular other than "portions of the rev file that should be written in sequence".
Daniel
(since when does shift+enter send in the webmail?)
> 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:49:39 CEST