On Tue, Nov 29, 2011 at 6:24 AM, C. Michael Pilato <cmpil...@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/
