On Wed, May 9, 2012 at 1:34 AM, Ivan Zhakov <i...@visualsvn.com> wrote: > On Wed, May 9, 2012 at 12:49 AM, C. Michael Pilato <cmpil...@collab.net> > wrote: >> On 05/08/2012 04:39 PM, Mark Phippard wrote: >>> On Tue, May 8, 2012 at 4:20 PM, Ivan Zhakov <i...@visualsvn.com> wrote: >>>> On Wed, May 9, 2012 at 12:09 AM, C. Michael Pilato <cmpil...@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. > Well, it seems things are more complicated: current mod_dav_svn implementation never sends <fetch-props /> tag and ra_serf always asks for properties, even if there is no properties.
-- Ivan Zhakov
