> I am not sure, why the post commit takes so long, but since I get the
> message regularily from eclipse that the file was altered on the local
> filesystem after commit, I am sort of sure, that the Subclipse plugin
> marks the files as dirty for whatever reason (probably it pushes up the
> date) and then eclipse recompiles all the dirty files, which at a stage
> of a huge commit results in a long post commit for doing the compile.
> I could be wrong with my guessing here, but I am rather certain I am not.
Subclipse doesn't directly touch your workspace files, we call Subversion
API which does all of the work. The first thing to do would be to check
your file modification times to see if the file has been altered by the
commit. There are some valid reasons that Subversion would do this:
1) You have the svn:keywords property set on the file being committed.
2) You have the use-commit-times=yes setting defined in your local
configuration.
With either of these two conditions, Subversion would update the file after
the commit.
As for Subclipse, we are notified by Subversion of every file you commit,
which is how we produce the console output. As part of that process we
notify Eclipse about each of these files -- we have to. I imagine that
Eclipse then notifies any builders for your project. I would assume that
most builders would ignore these notifications if the file had not been
modified. They are supposed to,
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Sat Jun 4 10:37:25 2005