On Fri, Feb 5, 2010 at 02:03, Berwyn Hoyt <berwyn_at_brush.co.nz> wrote:
> (Re-posted in plain-text as requested. If you want the links, use the
> html version).
> --------------------
> Hi folks,
>
> TSVNCache is fraught. I may have a way to solve it.
Great way to suck up to the developers. Insulting their work is always
a good way.
> *The problems *with TSVNCache:
>
> 1. it has generated an enormous number of issues on the forums
> because hogs the CPU.
> 2. it slows down explorer when it places the icons. The first time I
> view my "projects" folder, it takes windows 12 long seconds to
> display all the icons, and that explorer window is hung in the
> meantime. If I browse something else for a while and come back,
> it takes 12 seconds again. Even when put in the minimal "shell"
> mode, it takes 12 seconds. I don't really understand why it locks
"minimal" shell mode? In "shell" mode the cache isn't running at all
but the explorer extension fetches the status directly - which is
usually worse than using the cache mode.
> up explorer. It would be bearable if it still let me browse while
> it grabs the icons. This delay happens each sub-folder I browse
> into, so it takes a very long time to delve into the tree.
Works just fine on all my systems.
> *A solution:*
>
> Instead of scanning the drive all the time, use the the NTFS USN Change
> Journal <http://www.microsoft.com/msj/0999/journal/journal.aspx>. The
> MS indexing and service uses it for tracking file changes. There is MS
> code <http://msdn.microsoft.com/en-us/library/aa365736%28VS.85%29.aspx>
> to walk the journal. For your interest, the fsutil command line tool
> (installed at least on my XP pro) manages and tests the Journal to some
> degree.
>
> TSVNCache could use the USN journal and fall back on its traditional
> mechanisms on FAT drives. Developers, would this solve the speed problems?
Yep, you're the first one to bring a ten year old technology to our
attention, thanks a lot. We might have missed this for another ten
years or even longer.
(If you hadn't started your mail by insulting our work, I would write
a nicer response).
That said:
you don't understand the problem here. It's not the monitoring of
changes that's the problem but the scanning after a change was
detected. Because a change in a file doesn't mean that it's svn status
also changed, that's why the cache has to scan it.
So switching to using the NTFS journal to detect the changes won't help at all.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2445113
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-05 12:31:32 CET