non-recursive status of a directory?

[Tom Widmer]

Mark Hammond wrote:
>> 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.

It seems to me that TSVN and TBZR could be significantly different in 
implementation, due to the underlying working directory differences. In 
particular:

- In SVN, every directory acts like a repository root. It can be 
switched, etc. independently. BZR is very whole-branch centric.
- SVN allows non-recursive and arbitrary depth checkouts. BZR has no 
such things AFAIK, though a partial checkouts feature of some kind may 
be on the cards.

It seems to me that TBZR has an easier job on its hands, since for a 
first pass it really only needs to track branch roots, and not every 
directory. Also, only files returned by the status call would need to 
have their states cached - normally a short list. When it starts up, it 
could immediately status each branch it knows about (using the daemon 
process), and watch each one recursively for changes. When a change is 
detected, it could just fire off another status on the whole working 
copy (perhaps after a 2 second delay, to give whatever changes are 
happening time to happen - this is the obvious place where future 
improvements could be made). When a new working directory is found for 
the first time, it would do a full status immediately.

With that change, the default status to display for files in a working 
copy would be unmodified (or ignored, presumably using the same code 
that BZR uses to determine that). Only files mentioned by the last 
status call would return a different status.

[snip]

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

I'd say that it certainly isn't essential to an initial implementation, 
but might be useful to improve responsiveness to file changes in the 
future. (general Windows optimization of BZR would be equally useful for 
that I think).

WDYT?

Tom