Today I broke out my old patch[1] for teaching mod_dav_svn to, upon request,
include properties for added files/dirs in the REPORT response even when not
in send-all move. I finally figured out what I did wrong in the patch that
made the code still turnaround to fetch directory properties (again). See
attached updated patch.
I then ran the some tests with the patched client, and with and without the
patched server.
Without a patched server (so, with zero effect of patching the client all),
our test suite generates 135,060 HTTP requests. A checkout of an outdated
local copy of our Subversion trunk produced 3,623 requests.
After patching the server to effectively enable the change at all, a test
suite run generated 103,424 requests -- a saving of 31,636 requests over the
unpatched server scenario. And my checkout of the Subversion trunk now used
only 1,717 requests -- 1,906 (or 52%!) fewer.
I realize that some have been pushing for a different solution to the number
of turnarounds we're using, namely issuing Depth-1 PROPFINDs (which cover a
directory and all its children). That's still a good approach, and one that
has the advantage of being backwards compatible with older servers. But I
revisited my approach for several reasons:
- Issue #4106 ("serf checkout fails on XML escaped property names")
PROPFIND requests will always carry additional limitations over our
custom REPORTs in terms of how funky-named properties are transmitted.
- Issue #4173 ("ra_serf sends per-node PROPFINDs")
This is the issue which discusses the Depth-1 PROPFIND approach, and
it notes that the approach can "backfire if a single node is updated,
yet the directory contains many files with properties." I don't
think that precise scenario is a problem, since updates already carry
properties inline. But it does point to the sheer complexity of
the matter: an update which brings a single added file should need
only that one file's properties fetched; an update which brings in
a whole new tree, though, would want a Depth-1 PROPFIND for the new
tree to avoid all those niggly per-file-inside-the-new-tree PROPFIND
requests.
- There's an issue out there (which I can't find right now) that talks
about problems with Serf's requeueing of requests. I don't recall
the details, but my understanding was that in certain scenarios
the PROPFIND for a file might get (re)queued after its GET, which
presents ordering problems for the editor. Obviously, if there are
no PROPFINDs, this isn't a problem.
I misremembered Greg and Justin's attitude toward my approach, thinking they
were just flatly opposed. As I re-read the relevant threads, though, I
think it's clear that perhaps both my approach and their PROPFIND-Depth-1
approach would be valuable. The problem, as I see it, is that the
complexity of the PROPFIND-Depth-1 change is far greater than my simple
patch, and nobody is stepping up to own it.
So, pending discussion of this community, I plan to commit the attached patch.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-08-29 23:51:43 CEST