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

Re: Where is the list of known TSVNCache problems located?

From: behle <azverkan_at_yahoo.com>
Date: Wed, 28 Jan 2009 00:46:59 +0800

On Tue, Jan 27, 2009 at 5:44 PM, Simon Large <
simon.tortoisesvn_at_googlemail.com> wrote:

> 2009/1/27 behle <azverkan_at_yahoo.com>:
> > I've been reading through some of the discussion about TSVNCache
> regarding
> > all of the various issues with safely unmounting volumes, removal of
> > directories, and various other problems you run into due to applications
> > holding open handles for extended periods of time.
> >
> > With all the problems you run into with having it enabled, I was a bit
> > shocked to find that there are zero open bugs in the bug tracker. There
> > also doesn't seem to be any recent traffic on the users@ or dev@ list
> > related to it. Is there a page listing all of the known problems with
> > TSVNCache somewhere?
>
> The only known issue is that on some PCs the cache takes a lot of CPU
> time when it first starts up, and there is not a lot that can be done
> about that - the working copy crawl is an intensive task. There have
> been other vague reports of problems, but without details it is
> impossible to pin anything down. There are also problems caused by
> virus scanners, but again nothing we can do about it.
>

That's essentially my question, if there are known problems that tsvncache
introduces into a machine that was working correctly before TortoiseSVN was
installed, it doesn't make a lot of sense to have the feature enabled by
default. Power users are smart enough to turn the setting on by default and
non power users are likely to have to reformat their operating system (or
send it to IT) after they run into a problem that isn't apparent its being
caused by tsvncache unless you are familiar with Process Explorer (or
another equivalent application).

>
> > It certainly seems like the feature is too buggy at the moment to be
> enabled
> > by default, or at least there should be an installation prompt asking the
> > user if they want it enabled and providing them with the list of known
> > problems that their operating system is going to have with it enabled
> (even
> > if they don't use tortoisesvn on a daily basis, just having it enabled
> > causes various problems with the operating system).
>
> Do you have any information to substantiate this claim? The cache has
> been in use by thousands of users for the last couple of years. We
> would never claim that it is bug-free, but most people consider it a
> useful feature.
>

Over the last few months I've probably run into around a dozen separate
issues. The one I ran into yesterday that prompted to look through bug
reports is that safely unmounting eSATA drives in Vista doesn't work until
you kill the tsvncache process. I've also run into the issue in the past
with TrueCrypt volumes not unmounting correctly. I'll try to make a
benchmark for it, but some applications that are extremely directory access
heavy can see enormous slowdowns when tsvncache is running in the
background. Have also run into issues when trying to delete directories and
having it fail until you kill the tsvncache processes (I noticed from the
mailing list traffic that it's possible that this has since been fixed).
One proprietary application that I've had to use included a minifilter
driver that watched for directory and file timestamp changes and it had
problems operating until the tsvncache processes were killed. At the moment
I cannot remember what the other various problems were off the top of my
head, but they will probably come to me if I think about it more.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1059457

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-01-27 17:47:30 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.