Daniel Berlin <firstname.lastname@example.org> writes:
> However, while this works great remotely (since we can just grab the
> char after 'SVN' and do the right thing depending on the version), we
> strip the 'SVN\0' header locally in rep-strings.c, and send 'SVN\0'
> through when we read back the string to fake out the stream.
> This completely defeats the purpose of the version number in there, and
> guarantees that we can't easily change svndiff formats without destroying
> the data in the local repository. You have to resort to shifting tricks
> in the offset or something in your actual new algorithm, rather than just
> using a different number after the 'SVN' part.
The mistake is mine -- I didn't know the 0 was a version number,
although Greg Hudson did document that fact in notes/svndiff.
The goal wasn't to save space (as you rightly point out, it would have
been a pathetically small optimization).
It was because we divide the svndiff data in N blocks (on window
boundaries), and store the blocks separately -- this itself is mostly
to support planned future optimizations -- and we thought "Hmmm, this
is bad, the first block will be special if we retain the SVN\0
header; then it might be harder to treat like just another block when
we're doing delta-combination or something. We might have to
special-case it, yuck."
Note this is an explanation and not a defense :-). Losing the version
number is bad. We should either leave it there, or put one on *every*
window, or store it somewhere in the rep.
> But I really don't think getting rid of the version number on SVNDiff data
> before writing it out (i don't care whether we keep it *with* the data
> or not) is right.
Agree 100%, I'm glad you noticed it (I had forgotten we were doing
We can fix the repository, once we decide what the right
representation is. I've made a note about this in
while this thread continues; we'll want a new issue as well, of
course, but might as well gather as much info in the thread as can
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 21 14:37:07 2006