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

[Karl Fogel <kf...@red-bean.com>]

"C. Michael Pilato" <cm...@collab.net> writes:
> 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.

Hmmm.  Okay, I'll buy those arguments.  I hadn't thought about the
fact that new editors (driven by RA) are more likely to be implemented
than new RA layers are :-).

I'll review the patch itself now.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org