On Tue, Sep 30, 2008 at 5:12 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> 2. We get long-term maintainability. If gstein and I got hit by a
>> bus, how many people could step in and debug mod_dav_svn right now?
>> With this new system, we get an HTTP protocol that's just as readable
>> as svnserve -- one which instantly makes sense to anyone looking at
>> the network trace, and which is just as easily extended as svnserve.
>
> Is there possibility of making a common library that they both can use
> for most of the heavy lifting?
Yes, maybe... I alluded to this possibility in the designdoc. For
example, perhaps the code which parses (and unparses) svnserve's
"editor drive" s-expressions could be shared.
>> I know certain folks have put a *lot* of effort into making ra_serf
>> handle all of the insane edge-cases and quirks of DeltaV -- and I
>> don't mean to diminish that work. But for the long term, I want to
>> put my foot down and "stop the madness". If some high-powered admins
>> out there really need autoversioning, or want to put up a proxy-server
>> that can handle all serf checkouts under a huge traffic load, or have
>> transparent write-thru proxying -- then fine, mod_dav_svn can be the
>> proper tool for that job.
>
> A little confused by this last sentence. There are three points
> included in it. Wouldn't the first one be the only one that required
> mod_dav_svn? It seems like this new library could work as well, or
> better with the other two.
You're right. See the other thread with comments from gstein -- he's
pushing for cacheability as a feature, and there's no reason a
well-designed new protocol couldn't be designed for that (or write
proxying).
> Hey, couldn't we ditch wc-props too?
Yes, that's a DeltaV artifact -- basically a client-side cache of a
URL that represents a (rev, path) object. In DeltaV, a client isn't
allowed to construct such a URL -- it has to do a bunch of turnarounds
to 'discover' it, and hence the cache. In a well-designed protocol,
we could just make up a fixed URL syntax and have client and server
agree ahead of time.
(Note, though, that we could still do this right now, even in
mod_dav_svn. We could decide right now on a fixed syntax for a
(rev,path) object, advertise it to the universe, let clients depend on
it -- it just wouldn't be related to DeltaV.)
one of the useless DeltaV
> It seems like if we architected this right, it would not be too hard
> for someone to create an IIS add-in that also supported this feature.
> Ideally, the real work would be in a reusable library for the Apache
> module and maybe even svnserve and an IIS version could be created
> that used the same library?
Is there a demand for an IIS plugin? I've never heard of one, but
you're the one hearing from corporate customers.
But sure, the shared library you're imagining is just a heartbeat away
from a "librarized" svnserve. :-)
---------------------------------------------------------------------
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 00:50:55 CEST