Re: svn_delta_path_driver(), its purpose and future

2011-11-30 Thread C. Michael Pilato
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.

Re: svn_delta_path_driver(), its purpose and future

2011-11-30 Thread Hyrum K Wright
On Wed, Nov 30, 2011 at 8:12 AM, C. Michael Pilato wrote: > 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 "th

Re: svn_delta_path_driver(), its purpose and future

2011-11-30 Thread C. Michael Pilato
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

Re: svn_delta_path_driver(), its purpose and future

2011-11-29 Thread Hyrum K Wright
On Tue, Nov 29, 2011 at 4:20 PM, C. Michael Pilato wrote: > On 11/29/2011 04:56 PM, Hyrum K Wright wrote: >> I understand and expect that consumers of SDPD as currently >> implemented will need to use Ev1.  The problem is that they don't take >> very kindly to instances where Ev1 is driven in an a

Re: svn_delta_path_driver(), its purpose and future

2011-11-29 Thread C. Michael Pilato
On 11/29/2011 04:56 PM, Hyrum K Wright wrote: > It sounds very much like SDPD is simply a mechanism for doing with Ev1 > what Ev2 is explicitly designed for: operating on arbitrary paths in > the delta tree. All SDPD does is fill in the gaps so that the sender > doesn't have to worry about all the

Re: svn_delta_path_driver(), its purpose and future

2011-11-29 Thread Hyrum K Wright
On Tue, Nov 29, 2011 at 3:02 PM, C. Michael Pilato wrote: > On 11/29/2011 02:33 PM, Hyrum K Wright wrote: >> 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 e

Re: svn_delta_path_driver(), its purpose and future

2011-11-29 Thread C. Michael Pilato
On 11/29/2011 02:33 PM, Hyrum K Wright wrote: > 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

Re: svn_delta_path_driver(), its purpose and future

2011-11-29 Thread Hyrum K Wright
On Tue, Nov 29, 2011 at 6:24 AM, C. Michael Pilato 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 e

Re: svn_delta_path_driver(), its purpose and future

2011-11-29 Thread C. Michael Pilato
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

Re: svn_delta_path_driver(), its purpose and future

2011-11-28 Thread Daniel Shahaf
The docs seem pretty clear to me: svn_delta_path_driver() produces a depth- first editor traversal, where for each PATH in PATHS the portion in-and- below PATH is handled by the callback (including the open_*() or add_*() calls for PATH itself), and the portion of opening/closing the parent and anc