[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Ivan Zhakov <ivan_at_apache.org>
Date: Thu, 10 Jan 2013 00:10:25 +0400

On Tue, Jan 8, 2013 at 6:55 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 01/08/2013 04:20 AM, ivan_at_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
Received on 2013-01-09 21:11:18 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.