Status indicators

Tue Feb 6 19:00:04 GMT 2007

Yes, that seems to be it.

It seems unambiguously true that we're showing deltas, not merely state,
because we permit the user to specify two revisions to compare.

We could always add more columns to indicate state, I suppose.

A file may be

" D!IC": deleted, missing, ignored, conflicted

or
"+ !?C": added, missing, unknown, conflicted

>>Column 1: versioning / renames
> 
> 
> ^- This seems like 'tree shape' to me, even if it isn't represented to
> the user that way. Which would be 'Inventory versus Inventory' changes.
> We still have problems with 'Missing', but it is possible to consider
> that a Content change.

I really disagree here.  It's a state, not a change.

> But shouldn't Ignored/Unknown be put in the same
> place as Missing? At the very least they all fall into "Inventory says
> X, reality says Y".

I would say no, because a missing, ignored file causes different
behavior from a missing unknown file.  That suggests that if there's a
missing status, it should not override Ignored/Unknown, so they can't
all be in the same place.

>>>-D  path is removed
>>>?   but still exists on disk
>>
>>This looks like a bug.  I think it should be "- "
> 
> 
> Arguably true, but I *really* don't like using " " as a indicator of
> something going on.

But there is no content change going on.  It's misleading to say that
there is.

>>I suppose, but the changes reported by ChangeReporter are about
>>versioned files, specifically.
> 
> 
> I think it is incomplete then. At a minimum you have to handle "Unknown".

The previously-existing code handles unknown.  I don't think we should
handle it twice.

>>+M +K are impossible when the old tree is a RevisionTree.  The rest
>>ought to be achievable.
> 
> 
> I don't see how you could get '-M' or '-K' if the old tree is a
> RevisionTree, but I could be missing something. (At least I think you
> represent anything that could be considered '-M' as either '-D' or '- ')

This is the same bug as treating "- " as "-D".

In theory, this ought to do it:

$ echo foo> INSTALL
$ bzr remove INSTALL
abentley at balrog:~/bzr/bzr.ab$ ./bzr status --short
- -D  INSTALL
?   INSTALL

> Arguably using "New" to indicate that you reverted to Old contents is a
> mis-classification.

I would have preferred "Create", but we were already using "C" for
"Conflict".

> I think we need to be giving users information in terms of what a human
> would understand. Which means that "revert" is not the same as a merge
> in the opposite direction. (Think of what happened with "directory is
> deleted" errors)

I'm not sure why you're bringing merge into this, but "status" shows you
 exactly what has been done to the tree to change it from the basis
(modulo some bugs).  And that implies what would be done to restore it
to the basis.  So I think it's quite nice.

>>That means that it only applies to working trees, which is very bad,
>>IMHO.  I think it's less rigorous, because you're impicitly assuming
>>that the working inventory tracks the content associated with the basis.
>> Otherwise, you can't detect modification.
> 
> 
> I think we could consider RevisionTree as a degenerate WorkingTree,
> since it doesn't have the third state. (ie reality always == current
> record).

The point is we want something reasonable when the user does "status -r
x..y".

>>I've been trying to avoid reusing letters, which is why I used +/-
> 
> 
> I completely agree that we should try to avoid re-using letters (' R'
> looks a lot like 'R '.) I'm just trying to brainstorm.

Well, 'remove' is a particularly bad term for deletion, because 'bzr
remove' will cause '- ' to appear.

>>$bzr revert -r $REALLY_OLD_REVISION $FILENAME_IN_REALLY_OLD_REVISION
>>will get you the id back.  A little finicky, I know.

> Actually, I thought we fixed 'bzr revert' so that it looks around in
> several trees.

We did.

> I'm just wondering how we could present it to users who don't really
> want to think in terms of file ids.

Well, until now, the solution for kind changes has been "bzr remove X &&
bzr add X", so I'm loathe to change that so it no longer has the same
effect.

> And trying to support:
> 
> % bzr rm foo
> % bzr commit
> ## hack hack, commit, hack hack, commit
> ## oops, I really did want foo
> % cp ../trunk/foo
> % bzr add foo

Well with 'bzr status' thrown in at this point, it's pretty clear
something wacky is going on.  I'm not permanently opposed to changing
this behavior, but I'd like to hold off until we're sure it's not useful.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFyNA00F+nu1YWqI0RArzCAKCA/8lBcYjgBH1L5xE4OT08Rt3e/ACggGx0
VeOPxEjo8YALL5Y8XZDBuZ0=
=FxTn
-----END PGP SIGNATURE-----