At 10:24 21/01/2005 +0100, you wrote:
>I don't think that's true. If it would use that API, every filechange
>would result in an immediate change in the explorer view. But that's
>not the case.
Raymond Chen says that's how it works...
>If the program changing the files
>(adding/removing/modifying them) doesn't notify the shell about the
>change, explorer sometimes takes several seconds until the view
>matches the filesystem again.
Yes, but I *think* that's to do with how it aggregates change requests, not
how it detects the changes.
>I can see that especially when building
>the language packs while the exploerer shows the /bin folder.
>What it really does it to check every few seconds the whole folder
>which is visible in the explorer and then refreshes the view if
>necessary.
It's probably relatively easy to settle this with WinDBG and filemon, but I
certainly don't think it polls the visible files for their dates.
>Those NTFS journals aren't 'life', i.e. they can't be used to monitor
>changes in realtime. They're made for backup programs, synchronizers
>an the like.
OK, I hadn't looked at them in detail, but I wasn't terribly keen on the idea.
>And of course they won't work on network drives.
No, I don't think they're a great idea.
>Even though this looks brilliant, I think we still need a small cache
>in the shell extension part too. Otherwise we have to make too many
>IPC calls. I'm guessing we keep the 'one file' cache shared between
>all overlay handlers, and maybe the SVNAdminDir cache.
I agree with you about the 'one file' cache, though it needs to have a very
short lifetime to stop it becoming stale. I have currently implemented
this on the front of my cache, but as you say, that's the wrong side of the
IPC, really (though I ought to benchmark the named-pipe RTT to see if it's
a big deal).
Not so sure about the AdminDir cache, because it starts to need to do
things like check if an item is a directory or not before it can build the
path for the admin dir. In the current icon-overlay implementation, we
look in the cache before we do the admindir check.
You also get into the tricky boundary cases like a non WC folder which
contains some WC folders, which probably prevent just stripping the
right-hand end of a path string before adding .SVN.
But I agree, it does feel that preventing requests about unversioned items
even going across to the cache is a good idea, but we need some way to
verify that an unversioned folder doesn't contain versioned items before we
record it as such.
Cheers,
Will
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Jan 21 11:31:38 2005