[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: IBM RAD incredibly slow to update workspace after svn update

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2005-07-21 02:45:47 CEST

dan@tastapod.com (Dan North) wrote on 07/20/2005 05:30:02 PM:

> I'm not using the use-commit-times=yes, and it is a fresh checkout, but
> you did make me think of one thing that could be causing a similar
> - which is if the PC time is noticeably different from the repository
> and the bug you mentioned is still there in the version of javahl you're
> shipping.

We are shipping the JavaHL binary that was posted for 1.2 by the
Subversion devs. Also, I do not think the time of your PC vs. the server
is relevant. The entries file will contain the time of the file on your

> I'll check tomorrow, and in the meantime I'll try the svn cleanup as you
> suggest. Can I make a plea from the heart for an early release with the
> status checking fix, even if the other stuff you have planned for the
> next release isn't ready yet? :)

It is very easy to build yourself. Just checkout our core and ui plugins.
 Then do File -> Export and choose Deployable Features and Plugins. And
export the 2 plugins to a directory structure. Then copy the plugins over
the top of your install and restart with the -clean option. This last
part is slow in RAD.

There is a different but similar bug in the current HEAD version. It is
the one bug keeping me from making a new release. When you do a checkout
of a project, we are doing a massive amount of unnecessary status checks
so there is a long delay at the end of the process before you can do
anything. After that, everything is good.

One thing that has occurred to me is that a lot of this could be
perception. What you consider slow could be somewhat normal. I normally
work on Windows and RAD so I am used to slowness. This update problem
never bothered me so I didn't even know it was a problem. Someone else
found and fixed it. I do a lot of testing of Subclipse on various flavors
of Linux. I do this in VMWare partition on the same system. I have a
workspace on Windows that would take about 50-60 seconds to decorate. On
Linux in VMWare (less than ideal) the same projects checked out in a
workspace decorate in 2-3 seconds. This is because of performance of NTFS
vs EXT3. Since you are coming to Windows from Linux you might just be
experiencing this performance difference.

Finally, try running svn st from the command line from the top of your WC
and see how long it takes. Subclipse should be within the ballpark of
that time.


Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
Received on Thu Jul 21 10:45:47 2005

This is an archived mail posted to the Subclipse Users mailing list.