Peter Yamamoto wrote:
> I said "other than"... I've been leading up to this frustration point
> by asking other questions related to the behavior and problems we are
> seeing and there hasn't been a response.
Let's do a search for 'Yamamoto' on the mailing list:
http://svn.haxx.se/tsvnusers/archive-2006-04/0031.shtml
I answered.
http://svn.haxx.se/tsvnusers/archive-2006-03/0363.shtml
I answered.
No response? I don't think so!
Oh, maybe you mean that one:
http://tortoisesvn.tigris.org/servlets/ReadMsg?list=users&msgNo=2164
Well, after trying to explain to you several times how the cache works,
why it works as it does and telling you that keeping a working copy in
the drive root isn't a good idea, yes, I admit I ignored that one.
> This process *appears to thrash my disk for no reason*... You say it
> is because something changed in the folders. But I said it can happen
> at any time, even when I'm not working within the subversion folders.
Since you're keeping your working copy in the drive root, with all
'other' folders part of the working copy (unversioned, but still part of
it), of course you get that behavior.
Windows changes files often. There are plenty of log files, written
every few minutes. So there are files getting modified. And since those
folders are in your working copy, the cache recrawls the working copy.
> So is it any file operation anywhere on the machine that justifies a
> complete walk of the workspace?! Then why bother? Why not say any cpu
> usage is justification for a walk and be done with it?!
If you ask real nice, I might implement that just for you.
> Or perhaps there is a legitimate problem? For example, maybe a
> logging mode that would show the filemon type information (process
> and file operation) that triggered the walk would help? And as I've
> pointed out before, I've seen it traversing folders that aren't under
> version control (eg documents and settings). To what point...? It's
> easy, isn't it... that whole tree is un-versioned so all the status
> is un-versioned... So the only type of operation that would justify a
> complete walk of any subtree is a folder coming under subversion
> control...?
Yes. And since a change in a file *can* mean you added that folder to
version control, the cache has to check that.
> And even under version control, I don't understand why you say one
> file change causes the whole tree to have to be walked up and down;
> can you explain? If I modify a file in dir C, which is a sibling of
> D, and nothing else has changed, then how can that affect the status
> of anything in dir D? In the path to the parent of C and D, yes, but
> across the breadth of the tree, no, and below C, no. That does not
> make sense to me.
A->B->C->D
- all folders unmodified
- change file inside D
- fetch status of folder D again
- status of folder D changed to 'modified', since one file has now that
status
- folder D notifies folder C (its parent) of the status change
- folder C changes its status to 'modified' too.
- folder C notifies folder B
- ...
- folder A knows it has no parents to notifiy. So it starts a recrawl.
The recrawl usually doesn't even *touch* the filesystem. Only if some
items are marked as 'out-of-date' (i.e. its file timestamp changed or
its status got otherwise invalidated), then the status for that folder
the item is in is fetched again. Otherwise nothing is done.
> Check the code... Nice comment, back at you. I'm simply asking for a
No need to. I do that every day.
> bit of troubleshooting help from the community that knows the app the
> best. Is this the wrong forum for that?
No. It's the right forum. But you have to be nice here. I'm known to get
upset easily (ask some other users on this list).
> Basically it seems that TSVNCache is at the heart of the usefulness
> of Tortoise. If I don't have visible status information I may as well
> go to the command line.
We won't stop you from doing that.
> I'm trying to figure out if there is a problem here. So I first ask
> to see if I understand what the application is trying to do. This is
> so that I can verify that it is doing that or is it doing (way) too
> much work than necessary or is something "accidentally" triggering
> these walks or ...?
Just reorganize your working copy. Once you've done that, the cache will
work *much* better.
> So anyway, in the slightest chance you're interested, I've just spent
> 2 hours with filemon.exe and Show traffic to try and understand what
> I see happening against what you say... and basically I don't.
>
> The very first thing I did after reading your explanation and
> thinking about it, was touch a file. This caused a "mini-churn". It
> was not a full out traversal of the whole workspace which brings my
> machine to its knees (AMD X2 4400+, 2GB, SATA II Striped). But it did
> seem to bear out that changing one file *can* cause a lot of activity
> elsewhere in the tree (why again is still a mystery).
>
> Because, later, I tried the same thing, a touch of a file, and it did
> not cause the same behavior. This time it seemed that it did the
> smart thing and efficiently propagated the status change up the tree
> but didn't go off and scan other parts of the workspace. I tried the
> same thing with actual modifications of the file and a revert. Again,
> I did not see a definite pattern. Sometimes mini churn, sometimes
> localized activity. No operations during this time have caused the
> global churns that I have experienced on occasion but which you seem
> to imply should be normal and expected.
So you see, that's how the cache works.
If you really see the cache touching files without stopping, then you
might check what other apps you have running: if you have another app
constantly modifying files, then the cache will have to refetch the
status over and over again.
Maybe a virus scanner touching every file the cache touches? My best
guess would be that you have one or more files in your working copy
which your virus scanner checks every time it is touched.
* cache detects change in file
* cache rescans the directory (status fetch). By doing that, it has to
touch that file
* virus scanner detects file was touched. Opens file exclusively for
scan, closes it.
* cache gets notification that file was touched
you see, that will trigger an endless loop. And there's not much I can
do to prevent that. But since such virus scanners also interfere with
normal Subversion operations, we always recommend to configure those
scanners to *not* scan working copies.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Wed Apr 12 17:03:03 2006