I've been experimenting a little, and it does seem to be the refresh
process which is slow. A refresh of the full project after updating the
directories using the svn command line client takes a similar length of
time.
Would subclipse be able to speed this up by only instructing eclipse to
refresh the files it knows were changed as a result of an
update/switch/merge? Presumably a switch shouldn't require eclipse to
rebuild the entire project?
Cheers
Tom
Tom Walter wrote:
> Hi Mark,
>
> 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.
>
> Cheers
> Tom
>
> 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
>>> switch).
>>>
>>> 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 10:09:32 CEST