non-recursive status of a directory?
tom.widmer at googlemail.com
Mon Jun 9 12:52:40 BST 2008
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
> 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
- 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.
>> (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.
> * 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).
More information about the bazaar