Greg Hudson <ghudson@MIT.EDU> writes:
> * As I noted in an earlier thread, even if you didn't have this
> out-of-band information, getting a NULL handler from
> apply-textdelta doesn't allow you to save the cost of computing a
> base text checksum; you already had to provide that.
I thought the base checksums were often taken from a a pre-computed
source (the entry, or the FS), and thus not "computed" in any
expensive sense. Is this not the case?
Also, can't one always pass NULL for a checksum? That should be
documented, but even if it's not, it's still likely that the code
treats NULL checksums as "always matches", the same way it does for
all-zero digests.
> * ra_svn can get down to one round-trip delay per file. It doesn't
> make sense to be doing a "skeletal edit" negotiation on each file
> when it's really a property of the edit, not the file.
I trust your judgement enough that if you say the current API is
causing a problem, and your fix will solve it, then the fix is
probably a good idea. But I wish I understood the problem better (and
I know you've tried to explain it in earlier mails; it may just be me
being dense.)
How does making window handlers unconditional fundamentally change
things? I mean, some drivers lose a null check, but I don't see how
needing to always drive the handlers (instead of just sometimes having
to drive them) can really save cycles or even save code complexity.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 27 21:18:16 2003