Re: svn_delta_path_driver(), its purpose and future

On Tue, Nov 29, 2011 at 6:24 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 11/28/2011 05:34 PM, Hyrum K Wright wrote:
>> In working on the Ev2 shims, I discovered svn_delta_path_driver(), a
>> nifty little API whose purpose I haven't totally yet discerned. It
>> looks to be some kind of hybridization of the editor, allowing a
>> caller to handle some portion of the editor drive manually, though the
>> documentation has enough ifs, buts, and wherefores to make me a bit
>> unsure.
>
> I created svn_delta_path_driver() for those situations where we have a set
> of paths to be modified, the full set of which we know in advance -- we
> aren't discovering them via an editor-compatible-deep-crawl that's easy to
> hook directly up to an editor, for example.  It's primary value is that it
> does the work of figuring out which open_dir/close_dir pairs to fire off for
> intermediate directories (which generally *aren't* in that set of
> paths-to-be-changed), allowing it callback to act *only* on the "really
> changed" paths.
>
> The foremost uses which come to mind are client commits (which *do* perform
> a WC crawl, but flatten out the list of modified things long before using
> them to drive the commit editor) and anything that's driving an editor from
> the repository's "fs-paths-changed" output hash.

This sounds sensible, but I guess I'm having trouble meshing it with
my (albeit somewhat constrained) understanding of the delta editor.
If A wants to describe tree changes to B, B provides callbacks to be
invoked by A and A does so (within the confines of the API). Now this
new API shows up which changes those semantics somehow?

I'm just not sure what the interactions are, and hence I don't know
the best way to proceed in adapting them to Ev2. Will it require a
similar API, or will svn_delta_path_driver() just be obsoleted by Ev2?
 And in the meantime, is there a way to bridge the two? I just don't
know enough to answer those kinds of questions.

>> If I am correct, however, it would appear that this API is not
>> compatible with our current editor shims, which queue up all changes
>> made in an editor, and then play them back through the new shim.
>>
>> Any illumination by folks knowing more than I would be appreciated.
>
> I'd have to know more about the new editor to make a value judgment here.
> But I can probably help you grok the ..._path_driver() if need it.

Ev2 doesn't bother with a depth-first tree traversal, the sender just
invokes paths in whatever order it sees fit. There are a few obvious
restrictions, such as directories need to exist before their children
can be processed, for example, but it's much looser than the delta
editor. Also, the APIs are a bit more streamlined, in that it's not
legal to set the properties on a node multiple times in the same
drive, for instance.

To handle the conversion from the delta editor to Ev2, we create an
editor which receives all the calls from the sender, queues them up,
and then drives an Ev2 editor in the receiver. Likewise, a similar
shim exists which receives Ev2 calls, queues them up and then drives a
delta editor in the proper order. It's all terribly inefficient due
to the fact that the entire drive is stored in memory prior to being
translated and replayed to the target editor (whether Ev2 or the delta
editor), but it's also meant as a temporary measure.

However, svn_delta_path_driver() looks like it interacts with the
editor while the thing is being driven. It counts on all the prior
calls actually reaching the target editor before the callback is
invoked, which means it will have an adverse reaction to something
which queues up the calls and then replays them, since none of the
preceding calls will have succeeded by the time its callback is
invoked.

Now, after having written all then, I wonder if there would be a way
to set up a system whereby the delta_path_driver callback was invoked
during the replay of the queued items, rather than the initial calls
to them. It would involve a bit more shim code, but this may be the
better solution. Hmmm.....

-Hyrum

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/