[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: Make apply_textdelta unconditional

From: <kfogel_at_collab.net>
Date: 2003-05-27 20:35:01 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.