On Sat, 14 May 2011 22:46 +0300, "Daniel Shahaf" <danie...@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" <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. > > > > >
