On Fri, Jan 18, 2013 at 7:56 PM, Mark Phippard <markp...@gmail.com> wrote: > On Fri, Jan 11, 2013 at 11:27 AM, Ivan Zhakov <i...@apache.org> wrote: >> On Thu, Jan 10, 2013 at 12:24 AM, Mark Phippard <markp...@gmail.com> wrote: >>> On Wed, Jan 9, 2013 at 3:22 PM, Ivan Zhakov <i...@apache.org> wrote: >>>> On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato <cmpil...@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
