You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2013/01/08 15:55:57 UTC
Re: svn commit: r1430185 - in /subversion/trunk/subversion: include/svn_dav.h
libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
On 01/08/2013 04:20 AM, ivan@apache.org wrote:
> Author: ivan
> Date: Tue Jan 8 09:20:54 2013
> New Revision: 1430185
>
> URL: http://svn.apache.org/viewvc?rev=1430185&view=rev
> Log:
> mod_dav_svn: Advertise if server supports sending properties in update
> report in skelta mode.
Ivan,
What motivated this change? You have the server advertising a subfeature of
the REPORT functionality, and the client noting this fact, but the client
isn't actually using the note.
Besides that, it kinda breaks from the pattern we use for REPORT response
functionality, which is that the client says "I want you to respond in X
fashion if possible" and the server, in its response, says either "Sure,
here's my X-style response..." or just "Here's my [implied non-X-style]
response". (See the "add_props_included" report baton member in
libsvn_ra_serf/update.c, and the handling thereof.)
The advertisement you've added seems only valuable if it would prevent a
client from acting *at all* when the server does/doesn't support the inline
properties. Was that your intent?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: svn commit: r1430185 - in /subversion/trunk/subversion:
include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Fri, Jan 18, 2013 at 7:56 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Fri, Jan 11, 2013 at 11:27 AM, Ivan Zhakov <iv...@apache.org> wrote:
>> On Thu, Jan 10, 2013 at 12:24 AM, Mark Phippard <ma...@gmail.com> wrote:
>>> On Wed, Jan 9, 2013 at 3:22 PM, Ivan Zhakov <iv...@apache.org> wrote:
>>>> On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato <cm...@collab.net> wrote:
>>>>> On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
>>>>>> I'm thinking about interoperability between svn 1.8-serf client and
>>>>>> pre-1.8 server: currently we use non-bulk skelta mode and this leads
>>>>>> PROPFINDs and GETs for each file/directory. I've added option to
>>>>>> advertise inline props support to leave possibility to use bulk
>>>>>> (send-all) mode for pre-1.8 server by default, while relying on server
>>>>>> configuration for newer servers.
>>>>>
>>>>> Ah, I see. So the client can say, "If you're going to force me to do a
>>>>> zillion turnarounds, I'd rather take the all-in-one-response option,
>>>>> please." Seems reasonable.
>>>>>
>>>> Yes, that was my plan. The only argument that I found against this
>>>> approach that we will have many different modes depending of
>>>> server/client versions and configurations:
>>>>
>>>> client server behavior
>>>> 1.8.x-serf 1.8.x skelta-mode without
>>>> propfinds (unless configured by server)
>>>> 1.8.x-serf 1.7.x bulk-mode
>>>> 1.7.x-serf 1.7.x skelta-mode with propfinds
>>>> 1.7.x-neon 1.7.x bulk-mode
>>>>
>>>>
>>>> But it makes sense: upgrading only one part (server or client) doesn't
>>>> change network protocol, which is good thing IMHO.
>>>
>>> +1 from me.
>>>
>> Implemented in r1432139.
>
> I just tested this using a recent trunk version against a SVN 1.7.8
> server. One thing I noticed is that the client is still issuing a
> PROPFIND request for every folder. There was just the single REPORT
> request and no GET requests, but still a lot of PROPFIND requests.
>
> If the client issued the Neon-style REPORT request then shouldn't the
> response have contained everything it needed to avoid those PROPFIND
> requests?
Fixed in r1436236.
--
Ivan Zhakov
Re: svn commit: r1430185 - in /subversion/trunk/subversion:
include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jan 11, 2013 at 11:27 AM, Ivan Zhakov <iv...@apache.org> wrote:
> On Thu, Jan 10, 2013 at 12:24 AM, Mark Phippard <ma...@gmail.com> wrote:
>> On Wed, Jan 9, 2013 at 3:22 PM, Ivan Zhakov <iv...@apache.org> wrote:
>>> On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato <cm...@collab.net> wrote:
>>>> On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
>>>>> I'm thinking about interoperability between svn 1.8-serf client and
>>>>> pre-1.8 server: currently we use non-bulk skelta mode and this leads
>>>>> PROPFINDs and GETs for each file/directory. I've added option to
>>>>> advertise inline props support to leave possibility to use bulk
>>>>> (send-all) mode for pre-1.8 server by default, while relying on server
>>>>> configuration for newer servers.
>>>>
>>>> Ah, I see. So the client can say, "If you're going to force me to do a
>>>> zillion turnarounds, I'd rather take the all-in-one-response option,
>>>> please." Seems reasonable.
>>>>
>>> Yes, that was my plan. The only argument that I found against this
>>> approach that we will have many different modes depending of
>>> server/client versions and configurations:
>>>
>>> client server behavior
>>> 1.8.x-serf 1.8.x skelta-mode without
>>> propfinds (unless configured by server)
>>> 1.8.x-serf 1.7.x bulk-mode
>>> 1.7.x-serf 1.7.x skelta-mode with propfinds
>>> 1.7.x-neon 1.7.x bulk-mode
>>>
>>>
>>> But it makes sense: upgrading only one part (server or client) doesn't
>>> change network protocol, which is good thing IMHO.
>>
>> +1 from me.
>>
> Implemented in r1432139.
I just tested this using a recent trunk version against a SVN 1.7.8
server. One thing I noticed is that the client is still issuing a
PROPFIND request for every folder. There was just the single REPORT
request and no GET requests, but still a lot of PROPFIND requests.
If the client issued the Neon-style REPORT request then shouldn't the
response have contained everything it needed to avoid those PROPFIND
requests?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn commit: r1430185 - in /subversion/trunk/subversion:
include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by Ivan Zhakov <iv...@apache.org>.
On Thu, Jan 10, 2013 at 12:24 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Wed, Jan 9, 2013 at 3:22 PM, Ivan Zhakov <iv...@apache.org> wrote:
>> On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato <cm...@collab.net> wrote:
>>> On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
>>>> I'm thinking about interoperability between svn 1.8-serf client and
>>>> pre-1.8 server: currently we use non-bulk skelta mode and this leads
>>>> PROPFINDs and GETs for each file/directory. I've added option to
>>>> advertise inline props support to leave possibility to use bulk
>>>> (send-all) mode for pre-1.8 server by default, while relying on server
>>>> configuration for newer servers.
>>>
>>> Ah, I see. So the client can say, "If you're going to force me to do a
>>> zillion turnarounds, I'd rather take the all-in-one-response option,
>>> please." Seems reasonable.
>>>
>> Yes, that was my plan. The only argument that I found against this
>> approach that we will have many different modes depending of
>> server/client versions and configurations:
>>
>> client server behavior
>> 1.8.x-serf 1.8.x skelta-mode without
>> propfinds (unless configured by server)
>> 1.8.x-serf 1.7.x bulk-mode
>> 1.7.x-serf 1.7.x skelta-mode with propfinds
>> 1.7.x-neon 1.7.x bulk-mode
>>
>>
>> But it makes sense: upgrading only one part (server or client) doesn't
>> change network protocol, which is good thing IMHO.
>
> +1 from me.
>
Implemented in r1432139.
--
Ivan Zhakov
VisualSVN Team
Re: svn commit: r1430185 - in /subversion/trunk/subversion:
include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Jan 9, 2013 at 3:22 PM, Ivan Zhakov <iv...@apache.org> wrote:
> On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
>>> I'm thinking about interoperability between svn 1.8-serf client and
>>> pre-1.8 server: currently we use non-bulk skelta mode and this leads
>>> PROPFINDs and GETs for each file/directory. I've added option to
>>> advertise inline props support to leave possibility to use bulk
>>> (send-all) mode for pre-1.8 server by default, while relying on server
>>> configuration for newer servers.
>>
>> Ah, I see. So the client can say, "If you're going to force me to do a
>> zillion turnarounds, I'd rather take the all-in-one-response option,
>> please." Seems reasonable.
>>
> Yes, that was my plan. The only argument that I found against this
> approach that we will have many different modes depending of
> server/client versions and configurations:
>
> client server behavior
> 1.8.x-serf 1.8.x skelta-mode without
> propfinds (unless configured by server)
> 1.8.x-serf 1.7.x bulk-mode
> 1.7.x-serf 1.7.x skelta-mode with propfinds
> 1.7.x-neon 1.7.x bulk-mode
>
>
> But it makes sense: upgrading only one part (server or client) doesn't
> change network protocol, which is good thing IMHO.
+1 from me.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn commit: r1430185 - in /subversion/trunk/subversion:
include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by Ivan Zhakov <iv...@apache.org>.
On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato <cm...@collab.net> wrote:
> On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
>> I'm thinking about interoperability between svn 1.8-serf client and
>> pre-1.8 server: currently we use non-bulk skelta mode and this leads
>> PROPFINDs and GETs for each file/directory. I've added option to
>> advertise inline props support to leave possibility to use bulk
>> (send-all) mode for pre-1.8 server by default, while relying on server
>> configuration for newer servers.
>
> Ah, I see. So the client can say, "If you're going to force me to do a
> zillion turnarounds, I'd rather take the all-in-one-response option,
> please." Seems reasonable.
>
Yes, that was my plan. The only argument that I found against this
approach that we will have many different modes depending of
server/client versions and configurations:
client server behavior
1.8.x-serf 1.8.x skelta-mode without
propfinds (unless configured by server)
1.8.x-serf 1.7.x bulk-mode
1.7.x-serf 1.7.x skelta-mode with propfinds
1.7.x-neon 1.7.x bulk-mode
But it makes sense: upgrading only one part (server or client) doesn't
change network protocol, which is good thing IMHO.
--
Ivan Zhakov
VisualSVN Team
Re: svn commit: r1430185 - in /subversion/trunk/subversion: include/svn_dav.h
libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
> I'm thinking about interoperability between svn 1.8-serf client and
> pre-1.8 server: currently we use non-bulk skelta mode and this leads
> PROPFINDs and GETs for each file/directory. I've added option to
> advertise inline props support to leave possibility to use bulk
> (send-all) mode for pre-1.8 server by default, while relying on server
> configuration for newer servers.
Ah, I see. So the client can say, "If you're going to force me to do a
zillion turnarounds, I'd rather take the all-in-one-response option,
please." Seems reasonable.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: svn commit: r1430185 - in /subversion/trunk/subversion:
include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by Ivan Zhakov <iv...@apache.org>.
On Tue, Jan 8, 2013 at 6:55 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 01/08/2013 04:20 AM, ivan@apache.org wrote:
>> Author: ivan
>> Date: Tue Jan 8 09:20:54 2013
>> New Revision: 1430185
>>
>> URL: http://svn.apache.org/viewvc?rev=1430185&view=rev
>> Log:
>> mod_dav_svn: Advertise if server supports sending properties in update
>> report in skelta mode.
>
> Ivan,
>
> What motivated this change? You have the server advertising a subfeature of
> the REPORT functionality, and the client noting this fact, but the client
> isn't actually using the note.
>
> Besides that, it kinda breaks from the pattern we use for REPORT response
> functionality, which is that the client says "I want you to respond in X
> fashion if possible" and the server, in its response, says either "Sure,
> here's my X-style response..." or just "Here's my [implied non-X-style]
> response". (See the "add_props_included" report baton member in
> libsvn_ra_serf/update.c, and the handling thereof.)
>
> The advertisement you've added seems only valuable if it would prevent a
> client from acting *at all* when the server does/doesn't support the inline
> properties. Was that your intent?
>
Hi Mike,
I'm thinking about interoperability between svn 1.8-serf client and
pre-1.8 server: currently we use non-bulk skelta mode and this leads
PROPFINDs and GETs for each file/directory. I've added option to
advertise inline props support to leave possibility to use bulk
(send-all) mode for pre-1.8 server by default, while relying on server
configuration for newer servers.
--
Ivan Zhakov
VisualSVN Team