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

Re: DAV updates

From: <kfogel_at_collab.net>
Date: 2001-09-24 21:40:27 CEST

Okay, sounds good to me, I withdraw my uninformed commentary. :-)

Thanks for the explanation!


Greg Stein <gstein@lyra.org> writes:
> > This is an improvement, but it's still far from ideal, because it
> > involves at least one extra network turnaround. Am I correct in
> > assuming that the final goal is:
> >
> > 1. Client sends a wc summary to server.
> >
> > 2. Server sends back a tree delta, complete with diff data. The
> > diff data is infix, not postfix, so that an interrupted update
> > is still useful, instead of being an all-or-nothing affair.
> Nope. Never.
> The current model with turning around and doing a series of GET calls is the
> most optimal way to go. Consider the effects of caching at various points in
> the system (when I say "system", I'm referring to client/network/server). A
> tree delta with infix text deltas completely blows any chance of caching. It
> means that you're going to hit the DB on every update request. If you use
> the GET method, then caching proxies can cache the diffs. Heck, even
> *Apache* itself can do caching. Under consideration in Apache right now is
> how to handle gzip'ing data for delivery over the network. Part of the
> discussion is how to cache the output of that zip process, so it doesn't
> have to re-zip it on the next request.
> [ yes, I know that svndiff may not compress well (we should be able to
> disable Apache's compression for svndiff data), but updates can also give
> you new files, and compressing that full text is important ]
> So... we aren't going to move to infix. We will add wire-level compression
> (but that is also dependent upon Neon, IMO; I don't want to decompress
> within ra_dav)
> Cheers,
> -g
> --
> Greg Stein, http://www.lyra.org/

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:42 2006

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.