non-recursive status of a directory?

[Mark Hammond]

> I certainly don't want to impede performance. Note however that
> references to svn for performance are - well problematic. Last I recall
> checking our status leaves svn st for dead;

But isn't it likely that on a very large tree, asking svn for a non-recursive status of the root is likely to compare favorably to bzr doing a full status?

> In a totally unmodified tree it will stat everything.

And there's the rub!  tsvn has a very smart "crawler" - it crawls using a thread at idle priority, it's capable of knowing when Explorer is currently asking for items (so crawling is suspended), handling that the directory being requested is currently being crawled, uses a smart cache to prevent crawling directories is considers "fresh enough" (which works fine given that directories are "watched" so are effeciently notified of change), etc.

> > 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?
> 
> Its: 'directories are a poor proxy for dividing work up within the
> system'.

That is the same as the first option: while your statement is correct in the general case, this isn't the general case.  I maintain that for tbzr, it *is* a more appropriate option.  If you think it is productive to continue thrashing out the tbzr design until that becomes evident to you (or conversely, it becomes evident to me how we can be as efficient without it) then I will reluctantly do so.  On the other hand, if it can be accepted that tbzr would benefit from non-recursive status updates, the question simply becomes whether tbzr can have that facility, and if so, how.

Thanks,

Mark