On Fri, Nov 30, 2012 at 5:38 PM, C. Michael Pilato <cmpil...@collab.net> wrote: > On 11/30/2012 05:25 PM, Mark Phippard wrote: >> On Fri, Nov 30, 2012 at 5:23 PM, C. Michael Pilato <cmpil...@collab.net> >> wrote: >>> On 11/30/2012 05:00 PM, Mark Phippard wrote: >>>> On Fri, Nov 30, 2012 at 4:54 PM, <cmpil...@apache.org> wrote: >>>>> Author: cmpilato >>>>> Date: Fri Nov 30 21:54:35 2012 >>>>> New Revision: 1415864 >>>>> >>>>> URL: http://svn.apache.org/viewvc?rev=1415864&view=rev >>>>> Log: >>>>> Implement in ra_serf "send-all" mode support for update-style REPORTs >>>>> and their responses. (Currently disabled by compile-time conditionals.) >>>> >>>> Sweet! >>>> >>>> Would this also resolve the issue with svnrdump, or could it? When >>>> Serf is using this mode, I assume it is also now conforming to Ev1? >>> >>> I guess it *could* based on what I'm reading is considered the source of >>> svnrdump+ra_serf's problems, but I'm a bit confused -- I thought svnrdump >>> used the ra-replay API instead of the ra-update one? >> >> Guess I am more wondering if it was another area where the same >> solution could be applied? > > No, that's just it. ra_serf's implementation of the ra-replay API is > single-connection, just like ra-neon's was. What suprises me is that > svnrdump *does* use the ra-update API. > > Ah! I see why, now. When not doing an incremental dump, 'svnrdump dump' > uses the ra-update API to handle that initial checkout-like revision. After > that (and otherwise when in incremental mode), it uses the ra-replay API. > So yes, I believe svnrdump would be in fine shape over ra-serf if it was > asking the server to use this "send-all" mode, where document Ev1 drive > ordering *should* be honored.
So this sounds like pretty great news. Regardless what we decide to do for Serf with normal updates, it seems like we could unconditionally make svnrdump tap into the send-all mode and that would remove a release blocker. -- Thanks Mark Phippard http://markphip.blogspot.com/
