[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: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 9 Jan 2013 15:24:45 -0500

On Wed, Jan 9, 2013 at 3:22 PM, Ivan Zhakov <ivan_at_apache.org> wrote:
> On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato <cmpilato_at_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.

Mark Phippard
Received on 2013-01-09 21:25:16 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.