You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2012/11/30 23:00:44 UTC
Re: svn commit: r1415864 - /subversion/trunk/subversion/libsvn_ra_serf/update.c
On Fri, Nov 30, 2012 at 4:54 PM, <cm...@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?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn commit: r1415864 - /subversion/trunk/subversion/libsvn_ra_serf/update.c
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Nov 30, 2012 at 5:38 PM, C. Michael Pilato <cm...@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 <cm...@collab.net> wrote:
>>> On 11/30/2012 05:00 PM, Mark Phippard wrote:
>>>> On Fri, Nov 30, 2012 at 4:54 PM, <cm...@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/
Re: svn commit: r1415864 - /subversion/trunk/subversion/libsvn_ra_serf/update.c
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 11/30/2012 05:25 PM, Mark Phippard wrote:
> On Fri, Nov 30, 2012 at 5:23 PM, C. Michael Pilato <cm...@collab.net> wrote:
>> On 11/30/2012 05:00 PM, Mark Phippard wrote:
>>> On Fri, Nov 30, 2012 at 4:54 PM, <cm...@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: svn commit: r1415864 - /subversion/trunk/subversion/libsvn_ra_serf/update.c
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Nov 30, 2012 at 5:23 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 11/30/2012 05:00 PM, Mark Phippard wrote:
>> On Fri, Nov 30, 2012 at 4:54 PM, <cm...@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?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn commit: r1415864 - /subversion/trunk/subversion/libsvn_ra_serf/update.c
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 11/30/2012 05:00 PM, Mark Phippard wrote:
> On Fri, Nov 30, 2012 at 4:54 PM, <cm...@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?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development