On Tue, Sep 30, 2008 at 5:46 PM, Branko Èibej <brane_at_xbc.nu> wrote:
> 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.
Possibly. Downlevel support is not that hard if it is read-only, so
the answer might be to scrap auto-versioning from the "DAV add-on"
portion. I'd still be curious about auto-versioning, and what the
additional work *really* means.
Recall that svnserve was started as a simplification over Apache. But
since then, it has added multiple auth modes, logging, threading, and
all the other goodies that Apache was providing us that svnserve was
"going to stay away from in staying simple". I believe we may want to
consider auto-versioning from the start rather than bolting in on,
with the idea that mod_dav_svn gets deprecated, and mod_svn becomes
the new HTTP/DAV recommendation. And in that regard, the biz users
will *really* want the auto-versioning.
>> 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
Actually, the second rev *is* there. X-SVN-Delta-Base or some header
like that. And the response has a Vary: header with that in there. A
proxy can use that to cache the (rev, rev, path) response. And the
good ones *do* look at that Vary header. They basically *have* to in
order to function properly.
> 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.
I'd actually disagree somewhat here. How often does a *given* file
change? Sure, from update to update, there may be 20 revisions. But
file X might not get changed for a while, so working copies A, B, and
C all have that same, old version, and the 3-tuple will be the same
for all of them during an update.
This is precisely why the "delta base" URL is manufactured from the
*changed-rev* rather than the base-rev.
Cheers,
-g
Received on 2008-10-01 03:34:56 CEST