On Wed, May 9, 2012 at 12:49 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> 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.
>
We could include all properties if we know there are small. It seems
to be possible implement this on server side, but I'm not sure that
current client code is ready for mixing embedded and external
properties in REPORT response.
--
Ivan Zhakov
Received on 2012-05-08 23:35:17 CEST