"Roger Talkov" <rctalkov@appworx.com> wrote on 07/28/2005 06:44:54 PM:
> Using the latest subclipse, with eclipse 3.1 & svn 1.2.1, eclipse does
very
> frequent refreshes and rebuilds when nothing has changed. I tried
setting
> workbench preferences to prevent this with no luck.
What are you doing that triggers the rebuilds? I am not suggesting you
are doing anything wrong, just trying to get an idea as to where to look.
Did you run Team -> Update, Commit etc...? Surely you have to perform
some action to trigger this.
Martin made some nice improvements in this area in Subclipse 0.9.32.
Essentially we are watching for updates to the .svn/entries file and when
it is modified that triggers a status refresh. Martin improved that code
so that it does not more than it has to.
>From my own experiences one thing I have finally "figured out" is that
sometimes when you see Building Workspace in the status line that is not
really what is happening. This is especially true when it says it is at
0%. What is happening is that Eclipse is in the "builder stage" where the
builders are potentially going to rebuild something. When it is at 0% I
think that it is waiting for our process to finish refreshing its status.
When we complete the Eclipse process then does whatever it is going to do,
which will often be nothing. You should be able to look at date/time
stamps on your build artifacts to confirm this. If the date/times are not
being updated then nothing is actually being built. What you are seeing
is the delay while we refresh the status on files.
On Windows, the refresh of statuses can be really, really slow. The
Subversion status crawl does a lot of stat() calls which are not as
efficient on Windows as they are on Linux.
Another possible issue is that some of your files may not have been
modified but their date/time stamps do not match what is in the
.svn/entries file. For example, open a file add a space, then delete it
and save. When this situation occurs, Subversion has to do a byte by byte
compare to figure out that the file has not been modified locally. If you
have enough of these files it can REALLY slow down the status crawl.
Running the Team -> Cleanup option is supposed to fix this problem by
updating the timestamps that Subversion has stored.
There is nothing that we can do in Subclipse that fixes the core problem
here (status refresh is slow). All that we can fix is to be as
intelligent as possible about doing the refresh in the first place. As I
said, Subclipse 0.9.32 actually has some major improvements in this area.
It is always possible that there are more scenarios that we can optimize
that we do not know about. So that is why it would be helpful to have as
much information as possible about what you are doing to trigger the
status refresh.
Finally, one more point. Martin can correct me if I am wrong about this.
Let's say your local WC is at revision 100, but you repository is at
revision 101. The extra revision was made in some other part of the
repository, such as a different branch. If you do Team->Update, while it
is true that you did not get any visible updates from the repository, in
actuality every folder in your local workspace was updated to revision
101. This means that every .svn/entries file was updated. I *think* this
means we have to crawl every one of those folders to check the status
again.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Fri Jul 29 23:07:22 2005