non-recursive status of a directory?

[Mark Hammond]

> Given what I'm hearing, I don't really percieve non-recursive as a need
> for the tbzr code:

Sure - its not a *need* - but please take my word for it that tbzr's implementation would be "faster", in terms of user responsiveness, with it, and quite a bit simpler.  Similarly, the people running 'bzr status' also don't *need* non-recursive status, but the person who added the "todo" note, and the people who implemented svn thought it might be a helpful option to provide :)

Note that svn allows recursive or non-recursive.  tsvn explicitly chooses the non-recursive option for good reason.  tsvn has lots of real-world based tuning tweaks, which is why I'm trying to follow their model as closely as possible.  I think the reality is that on Windows, tbzr will be compared performance wise against tsvn and people will draw conclusions about the performance of bzr versus svn from that.

So no, I don't *need* it, but I believe I've excellent reasons for wanting it.

> You describe an iterative process whereby details on a directory
> accumlate, starting with 'not modified' and ending up with 'a
> reasonable UI flag'.

The thing is, in many cases, it is *not* necessary to recurse to the bottom of a tree to find the full status of a directory, so in some cases, the bottom children will *never* be looked at.  As soon as you find a modified child, at any depth, you could present the status of that directory.  Thus, asking bzr to recurse fully means far more operations than necessary would have occurred before the state can be shown to the user (or alternatively, more operations are wasted after the status is shown).  On a large tree, this could be a significant win.

But please don't take my word for it - I'm mirroring the implementation found at http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/src/TSVNCache/CachedDirectory.cpp

> (Or to put it another way - why iterate by directory, why not step by
> file at a time, and use internal iteration rather than external). We
> seem to do the same work overall.

Its not yet clear to me that iterating file by file will give me "missing" items etc, and I'd really be surprised if that didn't come at a significant performance cost - but regardless, I'm a little confused by your position.  Is it:

* tbzr doesn't need, or even *want* non-recursive status, and while you think it does you don't understand the problem.

or

* bzr doesn't provide non-recursive status, and its such an obscure requirement it is unlikely to do so in the short term.  Please make alternative arrangements.

or something else?

Thanks,

Mark