non-recursive status of a directory?

[Robert Collins]

On Fri, 2008-06-06 at 10:23 +1000, Mark Hammond wrote:
> > What will happen with renames ? specifically given:
> > root/left/
> > root/right/
> > root/right/was-in-left/
> > root/right/was-in-left/child
> > 
> > the status on left is not completed until right has been scanned (and
> > such scanning is triggered by bzr recursing from left's record to
> > right/was-in-left.
> > 
> > or are you planning to stop at the first sign of a modification?
> 
> Moves are tricky.  We are severly constrained by how much information
> we can convey using simple icon overlays.  So its probably helpful to
> think of this as a kind of "UI State", rather than the true "BZR
> Status" of an item.  In other words, the question here is more "what
> icon will we show in the case of a move" rather than "what is the true
> status after a move".  I expect that the tortoise menus would include
> a command that shows the "true" status of a directory tree in a
> dialog, and that command would just use bzrlib directly and allow it
> to recurse.
> 
> So to answer your question, I think that TBZR would probably show the
> 'left', 'right' and 'was-in-left' directories as modified, and 'child'
> as 'added (or ideally, we could have a new overlay specifically
> indicating "new file as result of move".)  Does that sound
> appropriate?  What icons would you expect to see in the above example?

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

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

Well, the underlying code for bzr iterates to generate status, if the UI
is a consumer of that generators output it doesn't need to conceptually
block and can indeed send notifications to the path&parents-of-path as
things get scanned.

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

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080606/498230e4/attachment.pgp