"Irving, Dave" <firstname.lastname@example.org> wrote on 04/10/2006 09:44:34
> You may have seen my mail from the users list earlier commenting on how
> a "switch" through subclipse is much slower than a "svn switch".
> Alexander pointed me in the direction of the switch command, and after
> checking out the source, I made the local at the end of this mail.
> I simply took out the refreshLocal invocation after the call to
> My switch time dropped straight down to 1min 25 (just 5 seconds more
> that a straight "svn switch ..." takes me from the command line.
> However, Im sure there are all manner of nasty side effects of doing
> this - which I will start to investigate this afternoon.
> One thing someone may possibly be able to help me with though: Why do we
> need to refresh the resource root for a switch, but not for an update?
> (UpdateResourcesCommand doesn't trigger a refresh.....).
> If decoration updates work for an update without a full refresh Im
> confused as to why they wouldn't for a switch?
I do not think there will be any "nasty" side effects. In the worst case,
there will be situations where the decorators do not update. In the case
of Switch, this is usually the project decorator does not update to the
new URL. However, in my own usage in the past I found this was
inconsistent. It probably had a lot to do with which files were updated
by the switch process.
With Merge the problem was similar. After some merges you would not get
the modified files indicator unless you did a Refresh.
I added the Refresh as a way to resolve these problems. In my own
testing, even in very large projects, the Refresh option always ran very
quickly provided that the files were not out of synch with Eclipse. It
basically was no different than right-click on a project and choosing the
Refresh option. If the project is in synch, this runs fast and no build
I think the real patch to this problem would be to take out the refresh
option but then also figure out the problem as to why the decorators do
not always update.
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Apr 10 15:51:38 2006