On Fri, Nov 30, 2012 at 5:38 PM, C. Michael Pilato <cmpilato_at_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 <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.
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/
Received on 2012-12-01 18:02:11 CET