At 17:58 31/01/2005 +0100, you wrote:
>- if the external cache can't be started for whatever reason (missing
>registry key with the path, missing exe, corrupt exe, ...) the explorer is
>unusable because of 100%CPU usage. I committed a small change to that part
>of the code which prevents hogging the system in such a case.
Thanks! I tend to be very slack about noticing such things on this
particular machine.
>- If recursive overlays are turned on, then _every_ folder above a
>modified file get's the modified overlay, even if the parent folders are
>unversioned! That means that even the drive icon get's a modified overlay.
>Now I don't know if that was Will's intention, and it might be even
>something users want - but I really got confused when I saw those overlays
>on folder's which I _know_ aren't under version control!
That's not the intention, I will have a go at this (probably not today though)
>(I hear the word "option" ringing in my ears ;)
I think it's undesirable. I don't think that the recursive stuff should
promote things from 'unversioned' to one of the 'versioned' states. It
probably also causes excessive crawling in some situations.
There are lots of things I don't like about the current implementation, but
it *does* make recursive status useable to me, and I really like
that. (It's great to have a reminder that there's something uncommitted
lurking.)
I have made the current versions of TortoiseProc *very* aggressive in
issuing ShellUpdate requests, and this has some undesirable effects in
sending unnecessary directory refresh requests. What I'd like to do is to
have TP issue 'cache invalidation' requests to the cache instead of to the
shell, and have the cache deal with issuing shell-update
notifications. Because the cache is aware of which items have changed
state, it can issue updates more sensibly. Obviously we can only do this
on installations which are using the external cache - where the cache
wasn't running, we'd just use the current method.
Cheers,
Will
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jan 31 18:36:27 2005