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

Re: svn ls -r BASE contacts server

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2005-02-05 18:44:00 CET

> While testing a fix for issue 165 - Compare with Base too slow, I came
> across something interesting (and unexpected). When you do an svn ls -r
> BASE the server is contacted. This is a major problem since 'ls' is so
> slow in the current version of subversion. I can't think of any reason
> why the server needs to be contacted, can anyone else? Should this be
> raised on the subversion dev list? I don't really want to subscribe
> because the traffic is just too much for me :)

I think that svn ls always contacts the server. If you provide a WC to the
command, it only uses the WC to obtain the URL and revision.


I think there was some talk a while back about adding a command line option
to not contact the server, but I do not know where that went.

I had a few thoughts on this Compare issue, but hadn't had time to look
into it:

1) Couldn't we somehow use svn status, or even our own decorator cache, to
tell us what has local mods, so that we do not waste time on all of the
unmodified items?

2) I think we should consider exposing svn diff as an option in the UI,
although now that I write it down, I suppose Create Patch is the same

3) The ideal would be if we could extend the Compare engine to work off
the output of svn diff. There is an existing Eclipse bugzilla for this,
but I do not know if we can count it. I am fairly certain the API is
already designed so that this is possible to do, it would just be nice if
Eclipse provided it "for free" since unified diff is a standard format.


Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
Received on Sun Feb 6 04:44:00 2005

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

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