Comment 22 for bug 343218

John A. Meinel wrote:
> Sure, something like:
>
> 1) Check the hashcache to see if there is a chance we are up-to-date
> 2) Read the contents, hold them in memory, compute the sha hash
> 3) If everything matched, return the text, else read from upstream.

"Hold them in memory" will fail for sufficiently huge files -- and long before that, it'll cease to be an optimization, by inducing paging.

Safer, though less optimal, would be to provisionally copy the local file, hashing as you go; then blow it away and recopy from the server if the hash didn't match.

For the smart-server case, how about the rsync protocol, using, as its inputs, the WT copy and the known-good data that upstream wants to provide? That'll go one better, by yielding the "use local data when possible" optimization down below the whole-file level. (This assumes a (technically and legally) usable rsync library, of course. Reimplementing the protocol from scratch seems a bit extreme :-))