[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-05-28 00:16:01 CEST

So, just to make sure everyone is clear, right now we have two redundant
ways of determining whether to send text deltas during an edit:

  * The editor may, when apply_textdelta() is called, set the window
handler to NULL, in which case the driver isn't supposed to send text
deltas.

  * Some drivers, notably svn_repos:delta_dirs(), accept an out-of-band
parameter which says "don't pass real text deltas, even if the editor
appears to be requesting them." (If the edit does request them, it gets
a single call to the window handler with a NULL window, as if the file
hadn't changed.)

Upon discovering this redundancy, my initial reaction was to propose
punting the second mechanism. But now I think it would be better to
punt the first one.

On Tue, 2003-05-27 at 14:35, kfogel@collab.net wrote:
> 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?

I guess you're right. Skipping the svn_fs_file_md5_checksum() or
whatever is probably only a small win. So, scratch that as a benefit.
But there is still the ra_svn benefit.

> Also, can't one always pass NULL for a checksum?

You can. But you don't know, until *after* you've called
apply_textdelta(), that the editor doesn't care about deltas. (Still,
as you point out, the work savings isn't as big as I thought it was.)

> 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.

Consider how you can marshal an apply_textdelta over the network, under
the current discipline.

The provider makes the apply_textdelta call, which is sent over the
network to the consumer. The consumer receives the call; it may or may
not decide it wants the text delta. We have to communicate that
information back to the driver before we can start sending windows:

    P -----------> C apply_textdelta
    P <----------- C I {want/don't want} windows
    P -----------> C windows

That's an extra round trip for each file. Why should this bit of
information be negotiated on a per-file basis when no editor could
possibly want to make the decision differently for different files?

If, instead, we rely on the provider to "just know" whether or not to do
a skeletal edit, then there is no need for a round trip:

    P -----------> C apply_textdelta
    P -----------> C windows (or none, for a skeletal edit)

Have I achieved clarity?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 28 00:17:03 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.