Greg Stein wrote:
> In general, I'm not crazy-opposed. You're entirely right: the vision
> of WebDAV (or "WebDA") came to fruition. DeltaV did not, so attempting
> to adhere strongly to DeltaV really makes little pragmatic sense.
>
> Within the scope of the (new) design, I *do* think it would be
> interesting to make it DAV-capable. i.e. is the URL namespace both
> DAV-aware *and* svn-aware? Given that DAV does not use POST, then I
> maintain you could probably mesh the two pretty easily. The "new"
> client would do some interesting GETs and POSTs, and a DAV client (not
> svn! a downlevel client) would throw in a couple PROPFINDs, and if we
> reach a bit, then some autoversioning around PUT and DELETE.
>
> IOW, what I might suggest is a mesh of your simplified protocol, with
> the related DAV support for Windows, Mac, Linux, and other software
> DAV-users. An admin could install mod_svn and get speed *and* DAV
> capability.
>
I agree that a SVN DAV plugin for dumb clients is a good thing ... well,
a major selling point in the non-techie parts of the corporate
environment, heh. But cramming both into a single httpd module seems
like serious overkill and suspiciously close to what we have now.
Unmaintainable nightmare, don't y'know. Keep 'em separate and simple.
> And yes, I want cachability of (rev, path) nodes. If a request can be
> satisfied locally, then that is a huge win. You say "serve out of
> RAM", and both will do that. But a proxy can do it on your LAN rather
> than the server via the WAN.
The problem is of course that most of the traffic from an SVN repository
server, at least as far as I've seen, is *not* (rev, path) requests but
(rev, rev, path) that return a delta. Since no two working copies are
likely to be in the same state at any one time, that implies an order of
magnitude more caching required -- and the better solution then is a
local slave repository that serves the read-only requests.
Just sayin'. There's nothing wrong in principle with making the new
protocol proxy-friendly.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-01 02:46:46 CEST