On 05/17/2012 09:45 AM, C. Michael Pilato wrote: > On 05/17/2012 03:43 AM, Justin Erenkrantz wrote: >> Again, the outstanding optimization to do on the ra_serf side is to >> reduce the number of PROPFIND requests and make that not proportional >> to the number of files - most likely either to the number of >> directories or only when custom properties are set. -- justin > > I've got a patch almost complete that: > > 1. teaches mod_dav_svn to send non-custom properties across the wire even in > skelta-mode, with a flag to say "Hey, there are some custom ones here, too!" > > 2. teaches ra_serf to assume that if the server is sending actual props > across the wire for a given file/dir, it shouldn't perform the PROPFIND > unless specifically told to do so by the server. > > I was toying with this a couple of week's ago when I made the > "fetch-from-the-pristine-cache" changes. I'll polish it up and post ASAP.
I just remembered why I abandoned this. My patch discriminated between "user-visible" and "non user-visible" properties -- the "entry props" versus everything else. I bailed when I realized that most of the files in our tree have user-visible properties set on them (svn:eol-style, etc.), so ra_serf would be dispatching PROPFINDs for those anyway. So I though, well, what if I include all "svn:*" properties in the REPORT, and only do PROPFINDs for truly custom properties. But then I realized that, in all likeliness, the biggest property that ever gets passed around through a Subversion system is one of our own: svn:mergeinfo. Next largest is probably svn:ignore. From there, I found myself wondering if there was meaningful (yet easily maintainable and explainable) way to divvy up what gets sent across the wire in the REPORT, and what must be explicitly PROP...FOUND. ;-) Is it "include all svn:* properties whose values are smaller than X"? Perhaps, "include (all) properties iff their combined value size is smaller than Y"? So, my patch has the necessary plumbing in place to make these sorts of decisions. It just doesn't know what decision to make. -- C. Michael Pilato <[email protected]> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
