Status indicators

[Aaron Bentley]

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

John Arbash Meinel wrote:

Here is the explanation from the help I just wrote:

- --short gives a status flags for each item, similar to the SVN's status
command.

Column 1: versioning / renames
  + File versioned
  - File unversioned
  R File renamed
  ? File unknown
  C File has conflicts
  P Entry for a pending merge (not a file)

Column 2: Contents
  N File created
  D File deleted
  K File kind changed
  M File modified

Column 3: Execute
  * The execute bit was changed

> -D  path is removed
> ?   but still exists on disk

This looks like a bug.  I think it should be "- "

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

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

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

I suppose, but the changes reported by ChangeReporter are about
versioned files, specifically.

> -N  ??? not sure if this can happen
> 	present in basis and disk but not in inventory?

You'd have to be comparing two working trees in order for the file to be
versioned in the old tree, but not present.

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

> -   Removed but no change
> +   Added but no change

"+ " is possible now.  "- " is possible in theory, but it looks like
there's a bug in this area.

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

- -D and ? is a bug, so...

> '+N' is always the case for a newly added file. It is not possible to
>   have any other combination with N,

Not with status, but you can do it with revert:

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

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

Not true for status anymore, and especially not true for revert.

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

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.

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

Perhaps we could stick ! in column 3, since it's impossble for the
execute bit to change on a missing file.

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

Missing is not a change.  Missing is a state.  That may be why we're
disagreeing so much.  But a file is missing when there's an inventory
entry and no file, whether that's because the file was deleted, or
because the entry was added, or even if the file is missing in the basis
also.

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

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

Bazaar considers them two different files.  Consider how weird it would
be if it was shown as " M File2", or worse, if no change was shown.

> Delete file Path and add Path as a link
> -D  Path
> +N  Path
> 
> versus
>  K  Path => Path@

There is a difference here, and that difference will affect behavior, so
it seems sensible to me.

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

If users want that, revert can do it.  Changing 'add' means that they
can no longer mark a file as different.

> (There
> has also been discussion about resurrecting a really old file id, but
> that would be very complex with the current data structures).

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

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

iD8DBQFFyLvP0F+nu1YWqI0RAiz5AJ96OQ2WUEn3GiUm1I8PaOtUhU+e7QCfZql+
lNGR6HdqkV2HddHBNDfY2h4=
=uOZv
-----END PGP SIGNATURE-----