Synchronize performance patch

Gentlemen,
 
after we've solved the issues with the synchronizeView, we've switched our
projects here to subversion and immediatelly hit the wall.
We have 3 projects in eclipse workspace, each more than 12000 files ;-(
The performance was simply unacceptable and subclipse nearly unsuable, so I
have to dig deeper into it ...
 
I took the usuall approach that I first optimized the things I thought are
in inner loops and only after a mediocre improvements I profiled the
application seriously ;-)
 
So what I did:
In SyncFileChangeListener changed the order of AND condition tests, so the
cheaper expressions are evaluated first, plus removed some unnecesary arrays
creation.
In LocalResourceStatus cached some values tested for null and later
evaluated again.
In StatusUpdateStrategy replaced the unnecesary construction of File from
IPath then getting its IPath again and such thigs.
For that I added pathForLocation() static method to SVNWorkspaceRoot.
I also reviewed the code I've introduced into SVNWorkspaceSubscriber,
removed some unnecessary method calls there and did some other small
improvements there.
 
>From the behaviour point of view, I've changed the StatusCacheManager, so
you can explicitely ask by which strategy (recusrsive/nonrecursive) you want
to update the status cache.
This was necessary due to the fact that when an .svn/entries file was
touched/changed only the immediate children were to be refreshed, but when
recursive
strategy was used, the status chache was updated for the whole tree.
 
Here I observed a bit strange behaviour which I suspect might be even
subversion's bug:
When you do an update on arbitrary level of directory tree and there is no
change in repository, none of .svn metafiles are modified.
However when you do an update on top-level dir, the top level's entries file
is touched although there was no update and the touched file's content is
unchanged too.
I believe I tested it also with command line client, but I'm not sure now
...
Anyway, this caused that when you did update on project level in eclipse,
the whole sync cache was being rebuilt and in project of 10000+ files it
sometimes took several minutes ....
 
Another behavioral change I did was in SyncFileChangeListener.
According to existing comment there, when a .svn metafile change event was
generated by eclipse, the metafiles should be refreshed and further trigger
to be raised to check for modification of child resources.
However the code was not behaving accordingly, since not the .svn metafile
but the parent directories files were refreshed instead. I've fixed that.
 
The last change I did was the way how refreshStatus() in StatusCacheManager
behaves.
When you call it with IResource.DEPTH_ONE or IResource.DEPTH_INFINITE it
will not only flush the old info from cache,
but also immediately fills the cache with fresh sync info (with the
appropriate update strategy).
 
I think that's it.
 
If I'll find some time I profile the plugin deeper, but for the time beeing
the improvements are significant enough ...
And if you don't mind I'd like to look at the monitors/progressBars since I
have a feeling that several longer lasting operations are not talkative
enought at the moment ...
 
Regards,
Martin