Look at the FileModificationManager and SyncFileChangeListener classes.
Eclipse does track the changes to the resources, but only to those done
within it.
Actually, all svn actions are performed by one of svnClientAdapter
implementations, i.e. outside the eclipse.
So one of the OperationManager features is to track changes done to files
within svn action and notify Eclipse afterwards.
(Notify means call the refreshLocal() on the changed resources. The resource
change deltas are then catched by those mofification listeners).
There are several complications there, like that the FileModificationManager
listens for the POST_CHANGE modication events,
where the Eclipse's workspace is locked for modifications. That's why there
is also that SyncFileChangeListener which is hooked to
PRE_BUILD events, where workspace is free again.
And that is actually the thing you see.
When the Eclipse's progress shows you "building project", it also means it
is processing the resource change deltas (PRE_BUILD),
i.e. the svn cache is refreshed from within SyncFileChangeListener.
So no "build" in the terms of (re)compiling code, but "build" in the sense
of "creation/update" of workspace (meta)data, including subversion related
synchronization infos ...
There is still a lot to improve there, no doubt, but a lot of performance
related problems are unfortunatelly caused by subversion itself.
Unless something will happen there, sublicpse will be slow. (On Windows
filesystems. E.g. Linux on ext3 is 3-10 times faster)
Look at the commit for example. In my daily job workspace there is a project
with >5000 files there in relatively deep tree.
When I do "Team>Commit" on the project level, it sometuimes takes 10-20
seconds just to display the commit dialog.
All this time is spent by call the "svn status" and we can't do much about
it ...
Martin
_____
From: Eugene Kuleshov [mailto:eu@md.pp.ru]
Sent: 11 October 2005 09:09
To: users@subclipse.tigris.org
Subject: Re: Performance: why rebuild even if no change after update?
Martin,
I wonder how subclipse currently subscribed for changes?
Eclipse already does all the job for tracking down all the changes and
notifying interested parties. Probably the simplest way to register for this
is to create a builder (usually comes with nature too). It will be called
automatically when Eclipse detect incremental changes in the project or on
full rebuild.
regards,
Eugene
Martin Letenay wrote:
Hi,
after an update that hasn't retrieved any file (because the
project is already uptodate), it seems to me that Eclipse
starts to re-build the whole project. Wouldn't it make sense
that subclipse inform Eclipse more precisely about which
files have been changed?
Yes. It would.
;-)
Well, it's know problem but there's not know 100% correct solution.
The very problem comes from the subversion itself.
Even in case there was no change done to the working copy, the (AFAIR)
.entries file in .svn meta folder is touched on the filesystem.
Subclipse then, does not parse the content of the .entries, but just listens
on the "resource modified" event reported by the underlying eclipse ...
There are few more such less-than-optimal features of Subclipse related to
performance.
The main problem is to find out reliable mechanism for various events - to
watch for modification to files done within eclipse (edits), to check
for modification caused by svn actions triggered by subclipse and also to
recognize the changes done to working copy by external tools (cmd line,
tortoise etc ...)
And of course not forgetting the reather poor performance of "svn status" on
Windows' filesystems
Martin
Received on Tue Oct 11 18:57:13 2005