On Fri, Jan 18, 2013 at 7:56 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Fri, Jan 11, 2013 at 11:27 AM, Ivan Zhakov <ivan_at_apache.org> wrote:
>> On Thu, Jan 10, 2013 at 12:24 AM, Mark Phippard <markphip_at_gmail.com> wrote:
>>> 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.
>>>
>> 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
Received on 2013-01-21 10:40:28 CET