Re: svn_delta_path_driver(), its purpose and future

On 11/30/2011 10:08 AM, Hyrum K Wright wrote:
>> 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.
>
> Actually, such calls can be delayed. Quoth the docs:
>
> * At least one implementation of the editor interface is
> * asynchronous; an error from one operation may be detected some
> * number of operations later. As a result, an editor driver must not
> * assume that an error from an editing function resulted from the
> * particular operation being detected. Moreover, once an editing
> * function returns an error, the edit is dead; the only further
> * operation which may be called on the editor is abort_edit.
>
> Now, that doesn't mean that calls to the SDPD callback shouldn't be
> similarly delayed as well, just that calling an editor handler
> function does not mean that the effects will happen *right now*.

You misunderstand me, or the docs, or both.

What is described here is *not* the delay of an open_directory() call, but
the delay of its effect on the receiver's end, and the delay of the
detection of any possible failures which might occur when said effect is
eventually manifested. We may all rest quite assured that when we called
editor->open_directory(), by golly the code on the other side of that
function call is going to run, and that not a thing more is going to happen
in the sender until that call stack returns. Or, we may all checks
ourselves into the nearest asylum.

What is further not described here is any deviance in the *ordering* of
editor calls or the effects of those calls. It stands against all reason
that the effect of add_file('A/B/NEWDIR/newfile') should "take" before the
effect of the add_directory('A/B/NEWDIR') which immediately preceded it, at
least insofar as Ev1 semantics are concerned.

> Just brain storming here, but since the users of SDPD are already
> operating in a way which is similar to Ev2, I'm wondering if they
> would be primary candidates for converting to Ev2 initially. Of
> course, that'd mean other work would need to be done to give them
> something to interact with, but it may be a possible way forward.

Seems likely. Of course, there's nothing to be done here until there's
actually an Ev2 that need a-drivin'. Or, if you wish to do the exercise
early, you could change those current consumers of SDPD to drive an Ev2->Ev1
adapter.

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