[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Um, why do we strip the SVNDIFF header for local writing

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-02-14 06:01:37 CET

Daniel Berlin <dan@dberlin.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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:07 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.