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

Re: [TSVN] RFC: New cache scheme

From: Will Dean <svn_at_indcomp.co.uk>
Date: 2005-01-21 11:30:56 CET

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

This is an archived mail posted to the TortoiseSVN Dev mailing list.