On 07 Mar 2022, Mark Phippard wrote:
I do understand the reasons why Evgeny thought pre-fetching
pristines for modified files as part of an 'update' could be a
good idea.
My recollection of the first version of this patch, commit needed
the
pristine and so had to fetch it before the commit happened. This
may
have been a reason it seemed like a good idea at the time for
update
to get the pristine.
Ah, maybe so; I didn't realize that.
If that was the motivation, then there's even less reason for
'update' to fetch pristines for modified files. Having the
pristine is not only unnecessary for the commit, in most cases
having the pristine is not even particularly *useful* to the
commit. These types of files tend to be non-diffable anyway
(i.e., not even binary diffable), broadly speaking and with
occasional exceptions of course. For example, a common such file
is a gigantic gzipped blob. Tiny changes in the uncompressed text
will lead to a completely different gzipped blob.
(I suppose it might be the case that if the first change is made
very late in the uncompressed text, then the revised gzipped blob
can, under some real-world circumstances, actually be bit-for-bit
the same as the original for a long initial prefix before showing
any difference. But this is a rare enough case that I don't think
Subversion should be trying to detect it and support it. We'd
essentially have to incorporate the rsync rolling-checksum
algorithm, or something like it, into our diff negotiation to even
get any advantage.)
And in the absence of fancy cross-network common-prefix detection
code that we're not going to write, this would just be
cost-shifting anyway. Whatever commit-time improvement one would
gain from having the pristine locally would be offset by the extra
time spent fetching the pristine to make that commit-time
improvement possible.
So... yeah. Let's not do that :-).
Best regards,
-Karl
