Re: Why do we check the base checksum so often?
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Sat, 4 Feb 2012 16:59:41 +0000 (GMT)
Hyrum K Wright wrote:
> Julian Foad wrote:
We're talking here about the delta editor (Ev1). The driver shouldn't have free rein to choose any base, because the receiver does not have all possible bases at hand ready to apply the delta onto. At least in the server-to-client direction (update etc.) the client probably only has one suitable base text per possible file. Either the server would have to be told what base texts it could choose from, or the client would potentially not be able to apply the delta until it first asks the server to send it the relevant base text, which would pretty much negate the point of having deltified in the first place. In the other direction, of course, we can now start to design protocols where the client picks any base text that it knows exists in the repository, and the server could be able to access it, now we have the rep-cache and the idea of looking up texts by their checksum. But ... that can't be what you're thinking of, I'm sure.
The empty stream is a special case. It's valid suggestion to say the driver should have the option of sending a full text, or a delta against an empty stream which is semantically the same thing. But retro-fitting that onto Ev1 isn't interesting at this point.
Now, if we talk about Ev2 (I know you're actually looking at the shims between the two), then we've explicitly designed that the mechanism for transferring texts is outside the scope of the editor iteself and so the driver and receiver code are responsible (assisted by respective layers above them) for co-ordinating in any way they want to. The Ev2 solution for deltifying text between driver and receiver could include (warning: possible hair-brained ideas): the receiver telling the driver what base texts it has available; the driver first choosing a base that's convenient for it, and letting the receiver request that base from the driver (out of band) if the receiver doesn't have it available; and so on.
I'm not quite sure I fully follow you at the moment, so I'm not sure if my reply is on the right track at all, but it's really sounding like you're up against a mis-match of responsibilities between Ev1 which sends deltas according to particular rules and Ev2 which is designed to be wrapped inside a driver-receiver pairing that knows privately how to deltify and recover to full text in any way it wants to. The shims obviously need to convert from the Ev2 deltification back (via a full text intermediary if necessary) to what Ev1 expects.
This is an archived mail posted to the Subversion Dev mailing list.