Re: svn_delta_path_driver(), its purpose and future

On 11/30/2011 12:59 AM, Hyrum K Wright wrote:
> Let me offer a concrete example, in the hopes that I can make some
> sense. I use the term "sender" to mean "the thing that is invoking
> the editor callbacks" and "receiver" to mean "the thing who is
> providing callbacks to be invoked". I believe these are the
> traditional uses of the terms; if not, I've got some more reeducation
> to go through.

(I've always used "editor driver" and "editor implementation", but whatever.)

> In libsvn_client/mergeinfo.c there is a function named
> svn_client__elide_mergeinfo_catalog() (or SCEMC for short). SCEMC
> uses SDPD to elider mergeinfo and uses a default Ev1 editor with only
> custom open_root() and open_directory() handlers[1]. It provides this
> editor to SDPD.
>
> Without the shims, everything works well, but when the delayed-run
> action of the shims is inserted, we get crashes. The reason for this
> is that with the shims, the SDPD callback is invoked prior to any
> open_directory() handlers of the editor are invoked, and the SDPD
> callback depends upon state which the open_directory() handler sets.
>
> Basically, the delayed processing of the Ev1 open_directory() handler
> is combined with the *immediate* handling of the SDPD callback, which
> results in out-of-order execution of the SDPD callback, and from there
> badness ensues. My thought is to move the shim insertion inside SDPD
> and make it clever enough to delay calling the SDPD callback until the
> Ev1 queue is played back, thus ensuring the ordering is then correct.

I guess this is the part where I'm confused. You can't "delay" an
open_directory() call -- it must execute, it must return, and when it
returns it must provide a new directory baton or throw an error.

I'm starting to wonder if these shims fit into a different junction than I'd
assumed. In fact, in this case, there should be no shims in use at all --
it's perfectly okay for SCEMC to use SDPD and an Ev1 editor now and forever.
 We should only be using shims where they are *required* to fix up interface
mismatches. No such mismatch exists at this call site which, as you say,
owns both the sender and the receiver.

Ah... I see what's going on now. You're trying to perform a double
transformation (delta->editor->delta) here. Now I understand what you mean
by delaying the open_directory(). It's the open_directory() of that
tail-end Ev1 that's delayed. So again, in this instance, the use of shims
is completely unnecessary. You must know that, so may I assume that you're
just trying to do this stuff for the sake of working out problems with the
shims themselves?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand