> There is no way to find out if an refresh (F5) is requested or not. We
> only get requests, if that's because of an F5 or not we don't know.
Ok. Too bad. We'll have to think harder then.
We could ask the Windows file notification API to tell us every time a
rename happens..
>> - Check that it has a .svn folder. If it doesn't, remove it from the
>> cache (or set a 'needs_update' mark on the item in the cache..
>> whatever's fastest) and skip applying the overlay
>
> Checking for an .svn folder will require a PathFileExists() which is a
> very expensive function and requires disk access. That's why this is
> cached and only done if the cache timeouts.
>> - Check the timestamp on the ".svn/entries" file (applies for all
>> files that's being checked) or the "<wc folder>/.svn/entries" file
>> (applies for all folders that's being checked). Compare it with a
>> cached value. If the timestamp has changed, the item needs to be
>> refreshed. To avoid the treewalk delay, set a needs_update flag on
>> the item in the cache scheduling it for a refresh and just return a
>> blank overlay on the item for now.
>
> Again here: all these are expensive function calls and are therefore cached.
Ok. It was my understanding that it was actually the insane amount of
disk accesses that a full treewalk incurs that was the problem.
A bit of calculation would probably be useful. Above idea demands 1
disk access per WC folder, and 1 acces _total_ for *all* WC files,
assuming you just request the timestamp of "<whatever>/.svn/entries"
and react accordingly if told PATH_NOT_FOUND. With ~10 msec seek time
on a modern harddisk, that amounts to ~1 sec per 100 SVN items you're
refreshing that's not in the filesystem cache (only inode needs to be
in cache, not the file itself). 20 items, which seems a reasonable
amount to have in one place, would then take .1 sek, wouldn't it?
Ok. Another alternative idea.
How about using Windows' file notification API?
Not sure how it works, but ideally you could just tell it that you'd
like to know any changes on folders that are under version control at
startup. (Perhaps we could even get rid of TSVN's specialized Delete
and Rename operations using this, but that's another idea..)
> Well, the issue is fixed. At least as far as it can be fixed without a
> severe performance degradation or not using the cache at all.
>
> So the issue *is* closed - when the cache times out it will be shown
> correctly, but not sooner.
"It's not a bug... It's a feature!" :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Mar 27 14:16:26 2005