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

RE: Re: What does TSVNCache do anyway?...

From: Peter Yamamoto <yamamotop_at_page44.com>
Date: 2006-04-12 09:51:44 CEST

 
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.

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.

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?!

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...?

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.

Check the code... Nice comment, back at you. I'm simply asking for a bit of troubleshooting help from the community that knows the app the best. Is this the wrong forum for that?

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.

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 ...?

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.

Just to be clear, when you say "fetch the status of the folder" you simply mean fetch from the .svn cache right? In other words, tortoise is only concerned (up until an update) of the status versus the "base" (checked out) version. In which case I really do not understand why one local change is a reason to walk anywhere but up. Not up and down and all around as you seem to imply (and as is apparent *sometimes* but not all the time, with actual behavior).

Anyway, it seems to be that the actual behavior does not correspond to what you say. So perhaps, you could be a little more understanding that maybe until I do read/debug the code, that trying to understand if there is a problem here or not is not as obvious as you might think?

Peter

-----Original Message-----
From: Stefan Küng [mailto:tortoisesvn@gmail.com]
Sent: Tuesday, April 11, 2006 10:32 PM
To: users@tortoisesvn.tigris.org
Subject: Re: What does TSVNCache do anyway?...

Peter Yamamoto wrote:
> Other than thrash my disk?

Nice comment. Thanks!
Of course, we wrote that cache only to annoy you.

> Is it really just trying to keep up-to-date status info?

Yes.

> It would seem to me that a filemon.exe type approach would be a lot
> more friendly than the disk thrashing type behavior of TSVNCache? Eg
> monitor file operations for changes.

Check the code. That's what it does.

> That way when I'm doing something completely different on my machine,
> it doesn't have to come to a crawl because TSVNCache decides to walk
> the directories "tsvncaching" for no reason.
>
> Am I missing something here?

Yes.
The cache monitors your disk for changes. When a change is detected, it has to crawl the working copy again. So why does it have to do that, after all, it monitors the changes? Well, a detected change doesn't tell anything about *what* was changed inside a file. You could have modified a versioned file, or you could have modified it so that it now is the same as it was before (you reverted your changes manually). So, it must fetch the status for that folder again.
And since the overlays are recursive, it has to recrawl the whole working copy to make sure the overlays reflect the correct status up and down the whole tree.

If it bothers you that much, you have two options:
* rename the TSVNCache.exe process and reboot
* use a nightly build from trunk and disable the cache in the settings.

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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Wed Apr 12 09:51:58 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.