[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Inline added-item properties in REPORT response

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 29 Aug 2012 16:04:27 -0400

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

  - 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

This is an archived mail posted to the Subversion Dev mailing list.