Status indicators

[John Arbash Meinel]

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>> Aaron Bentley wrote:
> 
>>> John Arbash Meinel wrote:
> 
>> I think the crux of the disagreement is whether we are showing deltas or
>> showing a state.
> 
> 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.

...

If you are defining "missing, conflicted, etc" as a state, I don't see
how you can say that "bzr status" is *not* showing a state.

You could argue that it is showing both. I think I could also argue that
we are showing state, and some state is determined relative to something
else.

There is definitely delta information, but there is also state information.

> 
> " D!IC": deleted, missing, ignored, conflicted
> 
> or
> "+ !?C": added, missing, unknown, conflicted

Speaking of which, how do you represent conflicted in short output? I
assume it is done like pending patches (at the end with a C), but I'm
curious.

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

I disagree, you can only be Missing if you were versioned. So you can't
be ignored or unknown if you are versioned.

If I'm wrong, please give me an example of a file that is Missing and
Ignored.

The best I can come up with is that between 2 working trees in one it
might be present but not versioned and ignored, and in the other it
would be versioned (you did bzr add) but it is not present (thus missing).

I'm not as concerned about showing this case (2 working trees), but if
it simplifies things to look at it that way, I'm okay with trying for it.

Part of all of this is I want to improve our "changes_from" interface,
to be able to include discussing unversioned files. It probably cannot
be called 'changes_from' because of the interface change, but I think it
is fairly critical to have a nice iterator interface for getting the
delta+state from a tree if we want to have a fast 'bzr status' command.

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

There is a content change from what the user would expect to be there.
They removed a file but it is still present. From a CS person's
theoretical point of view, there is no content change. But what if I do:

bzr remove foo
echo bar >> foo

Are you going to show
-M

To indicate that, oh you removed the file from the working inventory,
but then you also modified the file. Which is confusing from a user's
standpoint, but if you want to get technical "- " is actually
misrepresenting that case.


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

No the previously-existing code is totally *wrong* about how it handles
"unknown". And we *really* need to fix it. It costs a very significant
portion of time to re list all of the contents of all of the directories
that are versioned. We *really* should be doing it on the first pass
through the directories. (I'm talking 5-10s on a Mozilla sized tree, and
when the whole bzr status takes 10-20s that is a huge portion of time)

...

> 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

I really don't think this should be:

-M  INSTALL

At least as a user I would think that means it is versioning the
contents of INSTALL. Or at least trying to track it. Something like:
-?  INSTALL

Is a little more obvious. (You unversioned INSTALL and now it is
unknown).

I suppose the other is that you could get
-I  INSTALL

If it ended up falling under the Ignored category.

...

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

Sounds good. Can we come up with a synonym with a better letter?

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

Because we will (hopefully) be using the same output for a short summary
when you 'bzr update', 'bzr revert', 'bzr pull', and 'bzr merge', all of
which does this sort of thing.

Now maybe this can be done by internally having the last step call
show_tree_status().

However, what should 'bzr update' show you about files that were
modified but not committed, such that after update they are still
considered modified. It seems like we could easily just show the actual
changes that 'bzr update' applies to the tree.


John
=:->