Hyrum K Wright wrote:
> The Ev2 shims get in the way of how text deltas are transmitted, by
> reconstituting the full text, and then just streaming that to the
> receiver via svn_txdelta_send_stream(). I've got a patch which
> actually starts reporting the base checksum---which with the shims
> will always be the "empty" checksum---and it turns out that such a
> patch breaks the World.
>
> The reason for this breakage is that there are several places in both
> the FS and the WC that we check the delta editor's reported base
> checksum against some other value we have on hand which we *think*
> should be the base. Until now, these checks have always passed, since
> there was an implicit understanding about what the delta editor would
> use as its base.
>
> However, I think that these checks are wrong. They rely upon an
> implementation detail ("is the delta editor sending a text delta
> against the base we think it ought to?") rather than the result ("did
> we end up with the content we expected to end up with?")
When we (the WC update code for example) receive a text delta, we apply it to a text base that we already have, in order to create a new text. We need to be applying it against the correct base text otherwise the result would be nonsense (or the attempt to process the delta against the wrong base text would fail). The sender/driver doesn't tell us explicitly what base text we should apply the delta to, but it does tell us the checksum so we can confirm we're using the right one.
Does that answer the question?
- Julian
> It should be
> noted that we *already* check the result of the text delta application
> against what the delta editor provides in close_file().
>
> I've got a patch to remove this superfluous checking, but since the
> code in question is of Ancient Date, I wanted to make sure the above
> reasoning was correct before committing it. We catch a greater class
> of errors through the checking of checksums we already do based upon
> the *result* of the text delta, so such a change does not impact our
> ability to detect corruption.
Received on 2012-02-04 16:36:56 CET