On 15/11/2007, Josef Karthauser <joe.karthauser@geomerics.com> wrote:
> > -----Original Message-----
> > From: Simon Large [mailto:simon.tortoisesvn@googlemail.com]
> > Sent: 15 November 2007 10:55
> > To: users@tortoisesvn.tigris.org
> > Subject: Re: Re: TSVNCache appears to be I/O bound and locking the
> > machine.
> >
> > > From it's current behaviour it appears that things would run better
> > without the cache altogether! :)
> >
> > TortoiseSVN->Settings->Icon overlays-> use Shell for status instead of
> > default.
>
>
> Thanks, I'll try that.
>
> > The default behaviour is to show status recursively, that is, if there
> > is a change deep down in your working copy, the modified status
> > overlay will be propagated upwards to the WC root. To do that we have
> > to crawl the entire WC in a separate low priority process. But if it
> > locks explorer, that is a bug, usually indicating that TSVNcache got
> > stuck in a loop somewhere and is consuming 100% CPU.
>
> Well, according to Process Explorer, it is actually doing useful work.
> It appears to be scanning all the checked out files, and the evidence
> that it is reading them in their entirety is that the Read I/O stats are
> in the gigabytes! (My checked out repository is about 10Gb, and I've
> got three checked out copies of it).
You're right. Coincidentally there is another mail thread on the
development mailing list about a very similar problem. It seems the
low priority is not really effective at stopping the machine from
grinding to a halt due to being I/O bound.
> So, I'm confused, unless the cache process is generating checksums from
> the contents of the file, or something, why does it need to scan the
> entire contents? I thought that it could just use filesize and
> time/date stamps. Is that not the case?
That's all it *should* be doing. However, if the file timestamp is
changed and the size is not it will do a byte-by-byte compare because
it has no other way of knowing whether there is a change. If that is
what is happening, you can fix it by using TSVN->Cleanup which will do
that check and reset subversion's record of the timestamp if it finds
that the file really is identical to the BASE copy. Unless there's an
underlying bug in the SVN library ...
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Thu Nov 15 17:36:46 2007