Hi Mark.
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 effect
- 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.
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? :)
Great work as always,
Dan.
On Wed, Jul 20, 2005 at 02:33:04PM -0400, Mark Phippard wrote:
> 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.
> _____________________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
Received on Thu Jul 21 07:30:02 2005