Thanks for the reply. Refreshing the project beforehand does not make a
significant difference to the delay experienced at the end of the
switch. There are no other programs changing files in the project
folder. The number of files that change as part of the switch does not
affect the length of the delay a great deal either. If 3-4 files change,
there is still a delay of a minute or more.
And yes I understand about the builders etc. However from monitoring the
Progress view, the delay happens when only the "SVN switch" task is
running. It is not until after that task stops running that the various
builder tasks and 'Updating changesets' tasks fire up.
Something else I forgot to mention is that during the time the svn
switch task sits there unresponsive, eclipse can also lock up... so if I
switch programs, and then switch back to eclipse, eclipse cannot redraw
the screen until that svn switch task stops running.
Mark Phippard wrote:
> On Thu, May 1, 2008 at 8:50 PM, Tom Walter <walter.tom_at_gmail.com> wrote:
>> I've noticed recently that switching branches has gotten quite slow via
>> subclipse. It didn't used to be so bad but has started to be noticable in
>> the last few months. I'm not sure if it started after a particular Subclipse
>> update or not.
>> I'm not sure what is going on because the actual svn side of the equation
>> seems to happen quite fast according to the svn console. But after the
>> console reports 'Updated to revision X', the svn switch task sits there
>> seemingly doing nothing at something like 15% for up to several minutes
>> before completing. And only then do the 'Updating changesets for SVN
>> subscriber' tasks start running.
>> It's a little frustrating since the SVN switch task seems to block saving
>> and other user tasks until it's complete (even on files unrelated to the
>> Any idea what's going on? I am running Eclipse 3.3.2 in Windows XP, with
>> Subclipse 1.2.4, the and the SVN server is 1.4.2.
>> My project is quite large (4000+ files)
> At the end of the Switch (or merge) process, Subclipse has to
> "Refresh" your Eclipse project. Even a project much bigger than yours
> this should be very fast. When it is not fast, that is usually a sign
> that you have a significant number of files that are out of synch with
> Eclipse. For example, if you do Ant/Maven builds in the same folders,
> and Eclipse does not know about all of the modified files. What then
> happens is Eclipse recognizing all of these changed files slows things
> down as it fires events through the system letting all plugins know
> about them.
> To confirm, this, the next time you need to do a Switch try this:
> 1) Right-click on your Eclipse project and take the Refresh option.
> 2) Then do the Switch option.
> Since the project should already be refreshed the Refresh that we do
> should run faster.
> Now, one other thing you do not mention is how many files come down as
> part of the Switch. Because another thing that is going to happen is
> all of these changed files are going to kick off the Eclipse builders
> etc. to compile the files and report warnings etc.
Received on 2008-05-05 06:02:25 CEST