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

Re: svn commit: r1335639 - /subversion/trunk/subversion/libsvn_wc/adm_ops.c

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 8 May 2012 16:49:06 -0400

On 05/08/2012 04:39 PM, Mark Phippard wrote:
> On Tue, May 8, 2012 at 4:20 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>> On Wed, May 9, 2012 at 12:09 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>>> On 05/08/2012 03:35 PM, Greg Stein wrote:
>>>> One question: the ordering of PROPFIND and GET. Do you know if that is
>>>> a requirement, or simply that you were preserving prior behavior?
>>>
>>> Upon reflection, it's probably not a hard requirement. In general, I
>>> suppose it's easier (and more efficient) to cache properties and stream
>>> contents while we drive an editor than the reverse, so that's probably why
>>> that ordering was chosen prior.
>>>
>> Another option is to include properties in REPORT even in skelta-mode
>> if they are small. With defining small something like 0.5-1k.
>
> Agreed. I had forgotten that we would still need these roundtrips to
> get the properties. Maybe the REPORT request could at least indicate
> which items have properties. It would be better for performance if
> things like svn:eol-style and svn:mimetype were included in the
> request so we then only had to go back to the server for custom props
> (and we knew which files have them).

The REPORT request does include a <fetch-props/> type of indicator which
says "there's something worth fetching here".

I'm quite in favor of including, say, the "svn:" class of properties in the
REPORT response proper.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2012-05-08 22:49:44 CEST

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.