non-recursive status of a directory?

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 :)
|

I'm curious, though, how much actual time is being spent. It may be something
that we can completely optimize in the bzr internals. We want 'bzr status' to be
fast anyway.

As for the "non-recursive" case... I think there is a bit of a question as to
what that really means. Does "bzr status --no-recurse directory" mean give me
the status of "directory", aka 'ls -d' style, or does it mean "give me the
status of everything *inside* of 'directory'". (du --max-depth=1 directory).

When you were proposing it originally, I think you were conflating the two. "Is
directory added" would be "ls -d" style, and "tell me about the files and dirs
inside" would be --max-depth=1 style.

People have reasons to want both styles (what is the direct status of this path
that I'm giving you).

John
=:->


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhKJWAACgkQJdeBCYSNAAOV1gCg17Ad4bxc6t1i/HegP5YDcHAy
Bk8An1Cs6roEiwnLfnogZXVzn3uyhaGR
=EXgV
-----END PGP SIGNATURE-----