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

Re: RFC: an idea for making 'svn list' faster

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2005-10-24 08:23:39 CEST

On 10/22/05, Peter N. Lundblad <peter@famlundblad.se> wrote:

> If I understand correctly, the reason for APR to add these flags is
> because some of the information is really expensive to fetch on some
> platform and there's nothing APR can do about it.
>
> For us it might be different. Maybe we can do something about the cause of
> the problem instead of introducing API complexity.
>
> The problem is that we get and transfer entryprops in other places as
> well. For example, do_status will do this and the cmdline client will
> throw it away. Should we add flags here too?
>
> I'm not saying I object to this change if it is shown to be hard to
> optimize the lower level code.

I think the question becomes something along the lines of "are there
situations where this information is totally superfluous, and thus
should simply not be calculated?" The 'svn list' case in non-verbose
mode is one of these situations, and thus it seems like adding a
little more complexity makes sense. I haven't looked too closely at
the do_status case, but if there are situations where the extra work
is causing a noticable usability problem (like it does now with svn
list and large directories) I'd probably be in favor of adding this
kind of option to the interface.

I do agree though, looking in to speeding things up in the general
case is also good, but it's kind of hard to beat "just don't do it at
all" in terms of CPU and bandwidth used.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 24 08:24:52 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.