[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: DAV is complicated and slow? (was Re: [svndiff1] Accept-Encoding in mod_dav_svn)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-11-21 23:02:30 CET

Daniel Berlin <dberlin@dberlin.org> writes:

> On Mon, 2005-11-21 at 11:48 -0500, Marc Sherman wrote:
> > Daniel Berlin wrote:
> > >
> > > Honestly, I don't care what we do in mod_dav_svn. I only bothered to
> > > add svndiff1 support there for completeness. I have zero interest in
> > > DAV, as it is complicated and slow :)
> >
> > Just out of curiosity, is that a personal opinion, or is it widely held
> > by the dev team?
> >
> Personal opinion, but one held from watching DAV in subversion :)
>
> The only way to make it fast is to use custom reports.
> But if the only thing that knows how to interpret your custom reports is
> Subversion, being custom and all, then uh, you haven't won anything by
> using DAV :)

The benefits of DAV (such as autoversioning support, browsable
repository URLs via directory GETs, etc.) are not lost by allowing
mod_dav_svn to communicate solely via customer REPORTs when it's a
Subversion client doing the talking.

We could start using custom REPORTs and POSTs for all Subversion
operations, but additionally support the "real" DAV stuff necessary
for those aspects of DAV we care to shoot for. In other words, start
with a working, performant version control system, and then add
cheap(ish) goodies as desired.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 21 23:06:49 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.