Status indicators

[John Arbash Meinel]

Aaron Bentley wrote:
> John Arbash Meinel wrote:
> 

I think the crux of the disagreement is whether we are showing deltas or
showing a state.

To me, (especially for bzr status) we are showing a state, where some of
the state is determined based on a delta. (A file is added because it
didn't exist before. A file is missing because it did exist in the past).

I realize that revert/update/merge have different things to talk about.


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

...

>> -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. eg You removed it, but it is still there. That says
to me that something should be mentioned. Giving a blank space is
unhelpful as you have to really understand what the columns mean, and
know when a space means you can ignore it, and when it means something
weird is happening.

...

> This is fixed in the latest, and produces "+ ", which is consistent with
> the explanation above.

It is consistent, but IMO unhelpful.

...

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

...

>> These are probably not possible:
>> +M  modified (not in basis, in inv, content change on disk, there is no
>>               basis to compare content)
>> +K  kind change (not in basis, in inv, kind change, no basis to compare)
>> -M  in basis, not in inv, content change, see -D/?
>> -K  same as above -D/?
> 
> +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 '- ')

...

> $ bzr mv Makefile foo
> Makefile => foo
> abentley at balrog:~/bzr/bzr.dev$ rm foo
> abentley at balrog:~/bzr/bzr.dev$ ../bzr.ab/bzr revert
> RN  foo => Makefile
> 
> (this is another edge case, one I just fixed)

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

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)

> 
>> It seems to me like we could structure it a little more rigorously and
>> have the first column indicate changes between the basis tree and the
>> current inventory, and the second column indicate changes between the
>> current inventory and the working state.
> 
> 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).

But I can see how my statement is inaccurate, and think the Tree shape
versus Content changes is perhaps a better model.

...

>> I would rather have something clearer for 'Missing' just like we special
>> case 'Unknown'. But we are currently using ' M' to mean modified, and
>> really "Missing" is a column 2 attribute (not a column 1).
> 
> There are several combinations which cause a commit to omit a file:
> "+ ", "- ", " D", "-D".  It's been suggested in the past that silently
> zapping dangling inventory entries ("+ " or " D") is a misfeature, but
> until those types were visible, it didn't make sense to differentiate
> between them and
> 
>> Could we switch and change '+N' to '+A' which would give "Added"
> 
> I think that's confusing, because 'add' is a versioning operation, but
> you're proposing to use "A" for column 2, that is, creating a file on disk.

Well, we are creating contents on disk. But I understand that you are
considering the "add" to be the inventory entry.

I think as a human I respond better to "A" than to "N".

....

>> Another possibility would be to use ' R' to mean "Removed" rather than '
>> D' for Deleted. For some reason 'RR' for renamed but removed seems
>> better to me than 'RD' for renamed but deleted, though I still prefer
>> either 'RN' or 'R!' to indicate that.
> 
> 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.

...

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

Actually, I thought we fixed 'bzr revert' so that it looks around in
several trees. But yes, doing:

% bzr revert -r -100 filename
% cp ../new_contents filename

Will give you a newly added file with the same file-id as an old revision.

I'm just wondering how we could present it to users who don't really
want to think in terms of file ids. 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
% bzr commit
## now lets submit to main
% cd ../trunk
% bzr merge ../feature
### Why is foo conflicting, it has exactly the same contents?

But that is a side discussion.

John
=:->