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

RE: [Subclipse-dev] Performance regression in Quick Diff (0.9.32)

From: Martin Letenay <mle_at_whitestein.com>
Date: 2005-08-04 10:42:14 CEST

> Martin,
> Excellent work. I had a quick look at your changes and they
> looked really good. I will give your code a workout on the weekend

Well, the changes might look good, but Mark already found 2 bugs there ...

Anyway, these bugs pointed me to 2 questions, I'm not sure I have answer
for.

- when doing "svn status -u -v" subversion does really poor job for incoming
changes.
There is no url, no lastChangedRevision/Date/Author, no nodeKind there in
the returned ISVNStatus.

As one of my first pacthes for subversion, I've started to subsequently call
"svn info" to get the nodeKind on some resources.
The question is, should we try to get as much info from svn when doing
synchronize, and call svn info
an all (incoming) resources ?
The code might get a bit cleaner, but there's this obvious performance cost.
Is it worth it ?
Don't you know, is this incomplete ISVNStatus a subversion feature, or is it
going to be solved in some future release of subversion?

- the old SVNStatusSyncInfo#calculateKind() was using revision comparator to
compare lastChangedRevision of local and remote resource, to find out
whether there is an incoming change.
I think it is unnecessary, since we already have the text and prop
statusKinds for both local and remote resources.
Am I right or have I overlooked something ?
(It does not work anynmore anyway, since after these last changes, I'm
storing lastChangedRevision in both statuses, so they're always equal)

Martin
Received on Thu Aug 4 18:42:14 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.