Will Dean wrote:
> 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.
Well, it _has_ worked sometime ago ;) Just never as expected, and of
course it always had problems with the left treeview.
> 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 '/'
That's what I was aware of. I just didn't had the time to fix that, and
let's face it: most people don't even bother if they have to press F5 or
not. Sometimes I think it might be better to have a function that
doesn't work at all than one that works just sometimes. That way, people
_know_ that they can't rely on it.
[snip]
> 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.
Implemented your suggestion (including the fix for the commit method) in
revision 1894.
> 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?
The last-file mini-cache doesn't have anything to do with that.
Actually, it's the global cache (the big one) which sometimes still is
in effect (it didn't time out yet).
I was thinking of an IPC mechanism myself, but then I though it wasn't
worth the effort. Mostly because IPC can be a real pain in the ass ;)
> 2. Does it work on anything other than XP?
Yes, it will work on all NT based systems. Not sure about Win98 - but as
you said: who cares ;)
> 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.
That depends. If you have shortcuts on your desktop to files (not
programs), then they will get updated too.
> 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.
Well, I have been playing around with it for some time, trying to get
the treeview refreshed too. But since I've never got it working
correctly, I someday just left it as it was (knowing that it didn't even
work anymore). I still have some notes lying around so that I don't
forget to fix it. But as I mentioned, I've never had the time to do it.
> 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?
Can you create a patch for that?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Nov 2 18:49:21 2004