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.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2113128
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-05-08 15:16:30 CEST