Re: [PATCH] Teach ra_dav editor parser to filter unwanted data (for sparse directories)

Karl Fogel wrote:
> "C. Michael Pilato" <cmpilato@collab.net> writes:
>> Teach the ra_DAV editor parser to filter out unwanted stuff based on
>> the requested depth of the operation. This is useful for
>> compatibility with older depth-ignorant servers.
>
> Hmm, I have an annoying question, Mike. Do we even want to do this at
> the RA layer level? If we do it at the level of shared client and wc
> code, then we automatically get it for all RA layers. I think that's
> what Vlad Georgescu is aiming at in his (unfinished) patch here:
>
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=125228
> From: Vlad Georgescu <vgeorgescu@gmail.com>
> To: SVN Dev <dev@subversion.tigris.org>
> Subject: [PATCH] Make sparse-directories checkouts/updates \
> work with old servers
> Message-ID: <46052E15.4030108@gmail.com>
> Date: Sat, 24 Mar 2007 15:56:37 +0200
>
> Possibly you've thought this through more deeply and see an advantage
> to doing it at the RA layer level, let me know if so...

Oh, that's not an annoying question. It's a good question to ask!

When I started thinking about this problem, I was first going to head
straight to the libsvn_wc/update_editor.c code and start hacking. But as I
started thinking about how that code interacted with the RA layers and such,
I had to pause and consider if it was sufficient and/or sensible to tweak
the WC/Client layers.

Here are the two biggest thoughts floating in my head at the time:

   * libsvn_ra_dav uses a single bit of code (the stuff I patched) to drive
     the editors for update, checkout, export, status, merge, and diff.
     libsvn_ra_svn has the same kind of abstracted protocol-to-edit-drive
     code. Biiiiiig bang for the buck: changing those two pieces of code
     would cover all editor drives which uses those two RA layers. I
     wouldn't be surprised to find that ra_serf has a nice shared editor
     thing going on, too. But what about ra_local? Well, it turns out
     not to matter, because in the ra_local case, the "server" can't be
     running old non-depth-aware code -- there's no server!

   * The RA API is a public API. How nasty would it be to have to document
     in that public API that even though 'depth' flags are accepted to the
     RA functions, everybody that implements one of the editors driven by
     those functions must handle the possibility that the server isn't
     smart enough to drive the editor in the way you requested. In other
     words, not only do *we* have have to teach every single one of our
     server->client editors about the depth filtering, but so does everyone
     else who uses the RA APIs. Ewwww.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand