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. -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
