non-recursive status of a directory?

[Mark Hammond]

> There is also no question that the complete status operation of bzr
> performs well in comparison to svn, but given that our developers
> often turn off the recursive folder status in tsvn to make explorer
> more responsive I would hope the faster status in bzr would translate
> to faster status in explorer as well.

I'm interested in this, as my experience with the lastest tsvn is different.
My experience is that tsvn does remain *almost* as responsive when doing
recursive directory status.  Explorer itself comes back with an "unmodified"
status quite quickly, but suddenly disks start making a lot of noise and the
CPU is pegged at 100%.  The thread chewing 100% is at idle priority though,
so given enough memory the general responsiveness doesn't change that much -
but it is disconcerting (and I don't think it would be that hard to prevent
it taking 100% of idle CPU - small sleeps spring to mind ;).  However, once
the crawl is complete, the fact TSVN persists its cache means this happens
fairly rarely - generally you don't notice tsvn at all.  Further, while it
is doing this work it adds a notification to the task bar, allowing it to be
suspended.  It's also quite cute to see the folder icons are filled in as
the folders complete :)
 
Although bzr status may be faster, tsvn is taking the approach of "sacrifice
total wall time to keep explorer responsive", and as we intend to do
similarly, I'd expect that tbzr recursive status updates would behave
similarly to tsvn.  In other words, tsvn never directly asks svn for a
recursive status today, so any issues relating to the responsiveness of this
don't relate directly to the performance of svn recursing.  Therefore, I'm
interested to know how the experiences of your developers differs from the
above - eg, was it just explorer itself that got slower, or the entire
system?  Was it the 100% cpu which concerned them?  Was it the case that
their systems were already working hard/low on memory, so that idle thread
did cause problems?  Maybe they have an old tsvn?

FWIW, I was experimenting with this when browsing from the root of my "src"
directory, which has many many svn repositories directly under it, some of
significant size - bzr, tsvn itself, many copies of various Python branches,
Zope, most dependencies for those projects, private company repositories,
etc.  This entire tree is crawled during this process - many trees will be
able to be crawled much faster (but as you point out, many will be much much
slower) - but so long as the general responsiveness of Windows (ie,
explorer, other apps) doesn't change, this shouldn't be a problem.

Thanks,

Mark