Dan North <dan@tastapod.com> wrote on 07/20/2005 02:23:58 PM:
> I'm using subclipse 0.9.31 with RAD 6.0.0 (based on eclipse 3.0). I just
> checked out my first svn project, and the environment is taking an _age_
> to update.
>
> I monitored it with Process Explorer (procexp) and it seems to be
> veeerryyy sloooowwwlllyyy opening every .svn/entries file, stopping for
> a cup of tea, closing it and then moving on. It was also using a bunch
> of files in C:\Program Files\subversion\iconv, which is odd because I'm
> using the javahl client.
>
> I discovered and then unset the APR_ICONV_PATH environment variable,
> which at least accounts for the iconv nonsense, but RAD is still
> veeerrry ssssllllooowww - like several minutes - to update a number of
> projects that used to update in seconds.
>
> I'm using a mix of CVS and SVN projects if that makes any difference, on
> Win XP sp2. I have svn 1.2 installed locally on the PC, but I've removed
> it from the path so subclipse _has_ to be using the javahl client.
>
> The very slow workspace update occurs after a svn update whenever a file
> change has been received from the repository.
>
> Has anyone else experienced this behaviour?
The basic problem is that the status update logic is refreshing the status
of more than it has to. This has been greatly improved for our next
version.
However, it seems like you also potentially have a problem that the actual
updating of the status itself is very slow. In general this is true on
Windows, but it sounds like it is even worse than normal for you. One
possible issue is that when Subversion does a status check the way it sees
if a file is "modified" is by comparing the file size and date/time to the
values in the entries file. If the file size is the same, but the
date/time is different then it has to do a byte by byte compare of the
file to see if it has been modified. There was a bug in Subversion
pre-1.2 if you were using the use-commit-times=yes feature. When you
checked out a file with this feature the file timestamp is modified to
match the last commit time but the entries file received the current
date/time. This forces a byte by byte compare of every file making svn
status glacial.
The cleanup option is supposed to correct this. It would be worth trying
that option. If this is a fresh checkout, in theory that should not be
the problem.
I would put APR_ICONV_PATH back unless it made a big difference.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Jul 21 04:33:04 2005