Status indicators

[Aaron Bentley]

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

John Arbash Meinel wrote:
> 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.

Well, some invocations of status show state, but the two-revision form
shows only delta information.  I'm not saying it *never* shows state,
just that it *always* shows delta.

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

Yes, with C at the end, as per the previous format.

>>>But shouldn't Ignored/Unknown be put in the same
>>>place as Missing?

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

Oh, point taken.  You can only be ignored if there is content, you can
only be missing if there's no content.  I was thinking of removed + ignored.

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

I think that interface is a fossil now.  It binds in the wrong places--
renames being particularly bad.  If there are needs that
_iter_changes_from does not fill, let's discuss them.

I'll note that _iter_changes_from's output can represent unversioned
files that were never versioned.  But it won't show conflicts,

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

I don't think it's so theoretical.  +/- is what 'bzr add / remove' do.
N/D is what "touch/mkdir/rm/rmdir" do.

> But what if I do:
> 
> bzr remove foo
> echo bar >> foo
> 
> Are you going to show
> -M

Yes, once that bug is squashed.

> Which is confusing from a user's
> standpoint, but if you want to get technical "- " is actually
> misrepresenting that case.

How is that technically misrepresenting it?

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

It is still handled-- "inefficient" is different from "incomplete".  I
thought you were saying status --short wouldn't show unknown files.

Anyhow, this is a much bigger change than just ChangeReporter, as it
involves changing _iter_changes_from.

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

Well, okay, but _iter_changes_from never lists a directory, so I'm not
sure I see the win.  You still have to list the files.  Is it just that
you avoid traversing the tree to find the directories?

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

Well, we can suppress content changes to unversioned files if we want.
But I looks wrong to me, especially since we don't show ignored files.

>>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 don't know.  It doesn't look hopeful.

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

I don't know what "this" is.

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

I woudn't say "easily", because doing it properly entails translating a
TreeTransform into _iter_changes format, but yes, it's possible.

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

iD8DBQFFyPKD0F+nu1YWqI0RAgj0AJ9DkYwFQixUYheWAsGHDydH7Doe1wCfdNmT
6nuk+L4wK5X9UdqekdWlalg=
=MGo2
-----END PGP SIGNATURE-----