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

Re: Explorer hanging - 1.6.1

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Fri, 8 May 2009 15:16:21 +0200

Stefan Küng <tortoisesvn_at_gmail.com> wrote

> sneakypete wrote:
> > On Apr 23, 6:15 am, Roger Lipscombe <ro..._at_differentpla.net> wrote:
> >> Install "Debugging Tools for Windows", and then use the ADPLUS.VBS
script to
> >> get a minidump from the hung explorer.exe. Upload it somewhere and
then send
> >> the link. I'll take a quick look at it to see where it's hanging.
> >
> > The same thing is happening for me since the latest update - explorer
> > sometimes hangs for a minute or so when I browse to a working
> > directory. Killing TSVNCache.exe solves the problem. The working copy
> > is not on a network share.
> >
> > I've captured a minidump of explorer.exe and tsvncache.exe during a
> > hang, but as this is my work PC I don't particularly want to make it
> > public. Can I email the URL to somewhere? The "dev" email address
> > perhaps?
> Thanks a lot for those dumps!
> I think I found the problem that's causing this (but I don't guarantee
> anything). Committed a fix in r16285.
> Please, all of you who have this problem please try the next nightly
> build and report back.

Hi Stefan,

ever since, I experienced delays in the Explorer
as soon as TSVN is installed. For a long time,
I blamed our IT setup for these effects. But now,
while corporate IT seems to have a fair share in
that matter, it looks like TSVN is actually the
one triggering it.

* Showing the context menu or opening a folder
  in the Explorer takes 1..2 additional seconds.
  This is fine with me as long as it remains in
  that order of magnitude.

* Being disconnected from the LAN, the same operations
  lock up for about 10 seconds. It seems that it is
  sufficient that a network shared has been mounted
  before at all. Unmounting it will not help.
  Also, just accessing network shares (i.e. without
  associating them to a drive letter) does not trigger
  the unfortunate behavior.
  Once the effect is triggered, I will either have to
  reboot or to re-connect to the network - it is just
  to slow to work with.

* The delay will not occur for further accesses if
  the follow within a small window of time (10 secs?).

Of course, I tune my settings for speed such that the
usual suspects (virus scanner, overlays on NW drives)
are not likely to blame.

From what I have seen of the TSVNCache access code,
there are possible explanations for both effects:

* It seems that there is a sequential Explorer->TSVNCache
  round-trip for every item in the explorer. If that
  observation is correct, unfortunate scheduling could
  cost one or even two time-slices (~30 ms) per item.

  -> maybe, we could send the state for *all* nodes in
     the same folder as answer, if available. The explorer
     plugin could then cache the info for a few msecs.

* There is a 10 second time-out for TSVNCache to answer
  a request. So, the Explorer might frequently ask for
  unavailable drives / folders, for some reason.

  -> maybe, we can come up with an asynchronous protocol
     between TSVNCache and the Explorer. There must
     already be something like that in place for
     nested folder status updates. So, there would be
     no reason to wait for data that has not already been
     fetched by TSVNCache.

Now, I tested Wednesday's nightly (r16319) and this
is what I found:

* Speed is back to normal as it was during 1.6.0
  development, maybe slightly better than 1.5.x.
  The above mentioned effects are still there.

* There seems to be a serious flaw that should not
  be released with 1.6.2. No overlays are shown
  within the top-level folder of a large WC. Everything
  works fine for the top-level folder (e.g. /trunk)
  itself and for smaller projects (<=10k files)
  as well. F5, reboot, un-install TSVN etc. do not
  fix it.

What do you think? Shall we put a thorough revision of
TSVNCache on the 1.7 TODO-list?

-- Stefan^2.


To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-05-08 15:16:30 CEST

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

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