At 21:08 31/01/2005 +0100, you wrote:
>Oh yes, I was surprised! On the first activation, my PC was totally
>unusable for several minutes :-( I currently can not reproduce it, maybe I
>reboot and try again later.
Hmm. The crawling process is supposed to run at a low priority and pause
whenever the shell asks for more icons (i.e. the shell is always given
priority). I'm spoilt by using very powerful machines with very fast disk
arrays, so there may be something in here which I've overlooked, though I'd
need to have some idea what it was doing during that hang. The crawling
thread does not pause for other applications, so it may be that it just
generates an unbearable amount of disk traffic in some situations. Was it
thrashing the disk at this point?
A significant optimisation would be for the cache to examine the crawler's
work list and determine if a big chunk of it could usefully be done with a
recursive SVN status fetch, which would be much more efficient (though more
difficult to interrupt on a fine granularity...)
>* The status of a file/folder is not updated when only a file property
>changes. If I modify the content of another file in the same dir, then the
>file with the changed status is also marked as modified, but before that
>it still had the "normal" status.
I'll need to look at that - I haven't really taken much notice of file
properties yet.
>* When I enable the external cache and then open a working copy folder for
>the first time, then all files and directories have "normal" status which
>is wrong.
All *files* and folders, or just folders? Initially, the folders will show
their 'own' status, which is most commonly 'unmodified', then they'll be
overwritten with the recursive status when that's available. Files should
be right immediately, because they're handled completely differently and
don't get changed recursively.
>Only after some time (when the status cache is filled, I assume) then the
>correct status is indicated. That means TSVN is lying to me. It would be
>better not to display an icon overlay if the status is yet unknown.
It's better to follow the mailing list than to just assert a POV! This
was discussed-to-death last week, with no consensus about which approach
was best. There are pros and cons to all of them. Don't forget that what
the cache shows you first is not a 'lie' - it *is* the status of the folder
(not a made-up 'unmodified' status), it's just not the aggregate status of
all the folder's children.
>How does the icon refresh work? Does the backgound process permanently
>scan all directories in the background? Has it installed a file system
>hook? Or how does it know when a status has changed?
I really think you need to read back in the list. I have made some long
postings on this subject.
Basically, it keeps track of various file modification dates in both the WC
and the .SVN hidden folder. When it's asked for something by the shell, it
checks that it's not supplying stale info. (And also starts a background
recursive walk down the tree again.)
In addition to this 'demand only' technique, TortoiseProc is also kicking
the shell into asking for stuff (and at some point, I'd like it to have a
more intelligent converstation with the cache, too.)
>Except the problem above, the status cache seems to work quite well. Even
>if I modify a file down in the project tree, all it takes is a F5 in the
>exporer, and the folder status in the file list and in the tree view is
>updated correctly and fast. Good work!
Thanks! Thanks for testing it and supplying feedback, too. I am very busy
at the moment, but still have lots of improvements to make.
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 21:30:36 2005