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

Daniel Berlin <dberlin@dberlin.org> writes:

> > 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.
> >
> What advantage does this have over tunneling something sane over HTTP,
> and then just having a small dav implementation that supports the other
> stuff?
>
> Most of the hard to maintain code is in the custom reports and whatnot.

The hard-to-maintain code may in fact be in the custom reports, but is
only hard-to-maintain because it tries to remain DAVvish. There's
nothing inherantly hard to maintain about an XML report and XML
response.

That said, if we did choose to use something else that wasn't XML,
we'd be freed from some of the naming constraints we've had to deal
with there (propnames with colons, junk like that). I'd be fine, for
example, with tunneling the SVN protocol over HTTP.

-- 
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