"C. Michael Pilato" <cmpilato@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
Received on Thu May 3 21:54:00 2007