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

[TSVN] Studies into SVN::UpdateShell

From: Will Dean <svn_at_indcomp.co.uk>
Date: 2004-11-01 22:58:21 CET

Hi,

On my systems (all WinXP), I have found that TSVN has *never* updated icon
overlays after operations like add or commit. There is nothing recent
about this, I've never had any version which has done this
successfully. One has always needed to F5 on a folder to get it
updated. I suspect I am not alone in this, as it's a reasonably common
complaint on the mailing list.

Anyway, I decided to have a look at SVN::UpdateShell, and see how it worked.

Here's what I found: (Don't fix anything until you've read it...)

1. On XP at least, SHGetFileInfo fails with a / path. (Funny that I was
asking about this a couple of days ago - I think a lot of the SHxxx
functions can't cope with / paths.) UpdateShell calls preparePath, which
makes the path '/'

2. The SHChangeNotify functions should have had SHCNF_FLUSH passed as part
of their second parameter, not the first.

3. SHChangeNotify apparently needs the 3rd and 4th parameters around the
other way for Win98/ME (but who cares... ;-> )

Anyway, I fixed one and two, but it still didn't work.

After a bit of Googling around, I tried adding

SHChangeNotify( SHCNE_ASSOCCHANGED, SHCNF_FLUSHNOWAIT, 0, 0);

at the end. This didn't work either *UNTIL*, I took the other
SHChangeNotify calls out.

Then it started to work for the 'add' operation, which is a beautiful thing
to see for someone who's never seen it work in the past.

But it still didn't work for 'commit'. I think that was because
SVN::Commit was returning before calling ShellUpdate, which is an easy fix
if that's all it is.

I am currently running with ShellUpdate just containing the one
SHChangeNotify line. But this is not a panacea - here are my doubts:

1. It doesn't actually work *all* the time - I think there is possibly some
kind of race - perhaps just with the status cache in TortoiseShell - do we
need to think about some IPC mechanism for invalidating that when we do a
TortoiseProc operation, or are real-world operations actually going to be
slow-enough that that's never a problem? What about the last-file
'mini-cache' - is that a particular hazard?

2. Does it work on anything other than XP?

3. Can it cause huge folder updates (or even desktop icon redraws, which
are so tedious). I don't see this here, but I might just be being lucky.

4. What's the history of this function before my meddling? It was very
complicated before I got to it, and I suspect that Stefan might have been
through a lot of this already.

Anyway, things to think about perhaps.

Cheers,

Will

PS. I had a complete re-arrangement of all the #includes in TortoiseProc
to make it build faster (taking full advantage of the PCHs). Obviously
this means that I've modified almost every file. Is there any interest in
getting these mods into the codebase?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Nov 1 22:59:02 2004

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.