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

Re: testing DAV PROPFIND capabilities efficiently in r18513

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-03-06 21:53:58 CET

On 3/6/06, kfogel@collab.net <kfogel@collab.net> wrote:
> The log message for r18513 (which resolved issue #2151, "'svn ls' is
> slow over ra_dav") makes me wonder something:
> > ------------------------------------------------------------------------
> > r18513 | rooneg | 2006-02-17 17:52:54 -0600 (Fri, 17 Feb 2006) | 45 lines
> >
> > Fix for issue 2151 "'svn ls' is slow over ra_dav"
> >
> > This patch implements a solution to issue 2151. We now only request
> > the needed props in the PROPFIND for server listings. 'svn ls' is now
> > noticably faster. In most cases 'ls' takes about half the time and half
> > the bandwidth - In some case even better results.
> >
> > For backward compatibility, before doing the long PROPFIND we make
> > another simpler PROPFIND to see if the server supports the new type of
> > request (supports the deadprop-count prop). If it does we use the new
> > scheme and performance is improved - If not then we use the old scheme
> > and the slowness persists.
> Instead of adding an unconditional extra turnaround, why not just
> issue the request we want right away, and see if it succeeds or not?
> If it doesn't, we can just fall back to the old behavior.
> I might dig deeper if I get time, but before I go down that road, does
> anyone know off the top of their head why the usual try-then-fall-back
> strategy wouldn't work in this case? Its advantage is that it only
> does the extra network turnaround in the legacy case.

I don't think there's any reason it wouldn't work, but I do suspect a
speed hit on old servers for doing so, we'd calculate all the props we
need in the first request, then calculate them again when we did the
second allprops request, which kinda sucks. Not sure if that'd be
noticable or not though, or if we should care overly much for a legacy


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 6 21:54:34 2006

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