On Thursday, February 14, 2002, at 12:01 AM, Karl Fogel wrote:
> 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.
Okeydokey.
>
> The goal wasn't to save space (as you rightly point out, it would have
> been a pathetically small optimization).
>
Hey, in my main world (compilers), pathetically small optimizations
aren't all that bad.
> 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."
>
Makes some sense.
> 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.
>
It seems to make more sense to put it in the rep. The rep is what tells
us it's svndiff format, not the data.
Thus it makes sense for the rep to tell us *which version* of svndiff
format it is.
The version is certainly not a property of the data.
---------------------------------------------------------------------
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