On 11/30/2012 05:25 PM, Mark Phippard wrote:
> On Fri, Nov 30, 2012 at 5:23 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> On 11/30/2012 05:00 PM, Mark Phippard wrote:
>>> On Fri, Nov 30, 2012 at 4:54 PM, <cmpilato_at_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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-11-30 23:38:40 CET