Mark Phippard wrote:
>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.
hmm, that is a real shame. I don't relly understand why some commands
contact the server while others don't. This one could easily use the WC
to get the list.
>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
>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
It could probably be done (with hackery), but the compare stuff really
requires two trees so it can do the compare itself. I have played with
using the status command to populate the base resources and it is mostly
working. I think this will do as a solution for now. If the svn ls is
ever fixed the change can be reverted.
>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
would you display it as a compare editor or just the diff file?
>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.
This would be cool, but it wouldn't be very easy to implement with the
current compare infrastructure. You would have to create your own merge
viewer with associated range differencer (using the diff output as one
of the inputs). The problem is that merge viewers are associated to
file extensions or content type and there is already one for text files.
Received on Sun Feb 6 09:20:38 2005