Status indicators

[John Arbash Meinel]

Right now Aaron has done a lot of good work in creating the ability to
have short indicators to describe what is going on with the working
tree. I know he's thought about it, and I believe he is fairly happy
with the structure. For me, it isn't obvious what maps to what. Maybe if
we just have a simple structure it will be more obvious to me. All of
these are 2 letter codes, if you see a space, that is important

 D  path is missing
	present in basis tree, still in inventory, deleted on disk
-D  path is removed
	present in basis, not in inventory, not on disk
-D  path is removed
?   but still exists on disk
	present in basis, not in inventory, exists on disk

+D  path is missing
	not in basis, in inventory, not on disk
        (I get an exception in Aaron's status --short patch)


+N  newly added file
	not present in basis, in inventory, on disk
?   Unknown file
	not present in basis or inventory, on disk
        By the general logic, this could be " N"
-N  ??? not sure if this can happen
	present in basis and disk but not in inventory?

 M  modified
        in basis, in inventory, content change in working
 K  kind change
	in basis, in inventory, kind change


R   renamed
        in basis, renamed in inventory, no changes in content on disk
RD  renamed and deleted
	in basis, renamed in inventory, target missing on disk
RK  renamed and kind change
        in basis, renamed in inventory, kind change (ie, now a symlink)
RM  renamed and modified
        in basis, renamed in inventory, content change on disk

P   top-level merged patch
P.  ancestor of 'P' also being merged.
    There is one 'P ' for every pending merge, and however many P.
    depending on what ancestry is also being merged.


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/?

-   Removed but no change
+   Added but no change

?   cannot be followed by any of DKMN since it is unknown

There also seems to be:

  * Executable flag changed. This lays on top of anything that can have
    Modified

I'm starting to feel a little bit better about this layout, but I'm not
100% convinced yet. It stems from the fact that there are combinations
that cannot be achieved, and the fact that certain combinations are
always matched. Specifically:

'-D' versus ' D' versus ('-D' and '? ')
  The first is fully removed, the second is missing, and the third is
  removed but still present.

'+N' is always the case for a newly added file. It is not possible to
  have any other combination with N (not even +N* since * is a delta
  indicator) Further, AFAICT, '+' can also not combine with any other
  letter. So '+' implies 'N' and 'N' implies '+' (+ iff N)

I do like how it handles Kind changes, and especially how it can combine
with Renames.

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. I guess the second part is a
little loose, but think of applying the current inventory to the basis
tree, and then comparing that to the working disk state.

Which means that '? ' would be ' N'. I would be okay special casing it
to ' ?' (and also ' I' for ignored files)

In general '+' seems redundant since it can only coincide with N. I know
Aaron mentioned using '+ ' for files which were added but don't seem to
be present. To me this is more of an "added but missing" which is closer
to '+D' (since ' D' is missing)

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

Could we switch and change '+N' to '+A' which would give "Added" and
then we could use ' N' for "Notpresent"? To me, the letter "N" seems
more like a Negative statement than a positive New statement. So it fits
better for 'Not present' than for 'Newly added'.

We could also just switch and do ' !' to mean missing. Then we would
also have '+!' for a newly added file is missing.


I suppose the other way to look at the 2 column layout is that the first
column is the tree shape changes and the second column is the content
changes. So 'Missing' could be a content change. I'm not sure whether
Unknown/Ignored is a tree shape or a content change, but I think it
might still fit better as a content change.


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 probably rambled long enough, and this is certainly something that
can go through a lot of bike shedding. But it is something like I would
like to get right. Especially since it is something people are going to
use for scripting, etc.

I guess there are a few more edge cases to consider...
Delete File2 and Rename File1 => File2
-D  File2
R   File1 => File2

but that seems okay.
Delete File2 and add File2
-D  File2
+N  File2

that one seems a little weird. Especially for scripting/front-ends which
would want to know the state of the file.

Delete file Path and add Path as a link
-D  Path
+N  Path

versus
 K  Path => Path@


One thing that we *could* do is to make 'bzr add' default to using the
old file id if there was an entry at that path in the basis tree. (There
has also been discussion about resurrecting a really old file id, but
that would be very complex with the current data structures).

John
=:->