Re: [DISCUSS] delete ra_neon

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 <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development