[MERGE/RFC] Revert reporting #3707

[Aaron Bentley]

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

John Arbash Meinel wrote:
> Side note, you got the bug number slightly wrong. It is 3707 not 307.
> 307 is a Baz 1.x bug.

Well, next merge request... I guess...

> I don't really like having a separate field for 'added' and 'created'.
> Since you can't really have one added and deleted.

You can, just not when comparing a WorkingTree to a RevisionTree.

When comparing a WorkingTree to another WorkingTree, if the 'old' tree
has the file, but no inventory entry, and the 'new' tree has the
inventory entry, but no file, you would have that.

> I think you are doing it to distinguish from 'added' and 'not present'
> (missing). And maybe you feel the need to distinguish from 'added' and
> 'missing' versus just plain 'missing'.

The main reason was to distinguish between 'removed' and 'deleted'.  My
experience implementing revert is that people cared very strongly about
that difference, so I'm assuming they would want that difference
reflected in their display.

I think we can also avoid creating files in the case where there's an
unversioned file with the desired contents already present.  So then
we'd want to distinguish between 'added' and 'created'.

But there is also the issue that content modification can be
simultaneous with adding/removing.

> Certainly, whatever format we decide on should work for 'bzr status
> --short' as well as 'bzr revert', 'bzr update', 'bzr merge', 'bzr pull'.
> 
> Until now, we've always treated those as printing the log of the merged
> revisions,

I don't know what you mean by this.

>>> But there are also disadvantages:
>>>  - It would need to be able to indicate simultaneous 'add'/'remove' and
>>> 'rename'.

>>> The creation of backup files is especially problematic, because we don't
>>> technically create backups-- we rename and unversion the existing file,
>>> then create and version a file with the desired text.  So we would get
>>>
>>> - R  file => file.~1~
>>> +N   file
>>>
>>> When what we want is really:
>>> M    file
>>> (note that file.~1~ isn't mentioned)

> Your notation here doesn't seem to follow with your earlier notation,
> since your columns seem to mean something different.

As I noted, TreeTransforms introduce the possibility of adding/deleting
while renaming, so an extra column is needed to indicate renames.

> But certainly we don't want to show a file as unversioned and then
> versioned because we are creating a backup.
> 
> My gut says that TreeTransform is going to be too low level, and
> describe things in terms of how the filesystem was modified, rather than
> in logical terms of what happened to the tree.

I tend to agree.  It might be possible to re-filter the filesystem info
to give a more logical view, but...

> If I understand correctly, what you are trying to propose is:
> 
> 1) +-R
>   inventory entry was added, removed, renamed
> 2) NDMK
>   file itself is considered new, deleted, modified, kind change
> 3) *
>   executable bit changed
> 
> As I mentioned, I don't really like that +N is used to indicate an added
> file. It would be a lot nice to just have "A " like other systems.

Sometimes the file may be only added, and not created.  I didn't want to
use "A" because then "R" would be 'removed' not 'renamed'.

> While I don't think we want to reproduce all of SVN's idiosyncrasies, it
> at least gives us a point of reference.

Certainly valid.

> 
> ' ' no modifications
> 'A' Added
> 'C' Conflicted
> 'D' Deleted
> 'I' Ignored
> 'M' Modified
> 'R' Replaced
> 'X' item is unversioned, but is used by an externals definition
> '?' item is not under version control
> '!' item is missing (removed by non-svn command) or incomplete
> '~' versioned item obstructed by some item of a different kind
> 
> 
> We don't need "Replaced", though if you did delete + add we would need a
> way to indicate that.

You mean remove + add?  delete + add is an error if the file was already
versioned.

> So maybe we do want Replaced... That said, we also
> need Renamed. And maybe something for "illegal" (as in something that we
> cannot version, like a socket/fifo/illegal filename)
> 
> We don't need '~', since that is equivalent to 'K'.

Also, I don't think we want 'C', as conflicts don't really fit a diffing
model.

> They use '!' to indicate missing. To me, it is fine to use that whether
> it is missing because it was newly added, or whether it was added a long
> time ago, and just now cannot be found. I'm not super happy with '!',
> but it is ok.

I don't know what "missing because it was newly added" means.  If it's
added, how can it be missing?

> Compared to SVN, we only really need 2 columns, 1 for the entry state,
> and 1 for the metadata state.
> 
> What if instead of treating "renamed" in the first column, we put it
> into the second column. Then you would have:
> 
> 
> A   added
> D   deleted
> M   modified
> MR  renamed => and/modified
> !   missing
> MR* renamed => modified/and/executable
> KR  renamed => kind/change/
> !R  missing => and/renamed
> 
> 
> 'Kind' is a superset of Modified, and you can't have an Added + Kind
> change, unless you want to treat delete file, add directory as a Kind
> change instead of a new entry.

You can, when comparing two WorkingTrees.

> We also need to figure out how we want to handle the dichotomy between
> file ids and file paths. So if I do "bzr rm x; bzr mkdir x; bzr status"
> what should we get?
> 
> D   x
> A   x/

I prefer this one.

> 
> or should it be
> 
> RK  x/

I think 'replaced' is a bogus concept.


> It is arguable that we could actually get rid of column 2, and just have
> the presence of "old =>" indicate that the entry was renamed. It *is*
> ambiguous if someone versions a file with " => " in its name (no quotes).

What kind of lunatic would use '=' in a filename :-)?

> Probably '//' isn't terrible. It isn't very obvious, but you could
> probably pick it up quickly. Though we really do want the tool to be
> easy and understandable, at least as much as possible.

I guess I could live with it, but I'd rather just escape any real "=" in
the filename.

> Honestly, I think our current "bzr status --short" output works very
> well.

Well, as I noted in my previous email,

>>  - they have no way to represent a 'kind' change
>>  - they don't differentiate between 'renamed' and 'renamed and modified'.
>>  - they can't indicate file versioning operations separately from file
>> creation/deletion

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

iD8DBQFFpXoZ0F+nu1YWqI0RAo1rAJ4ymWGb+scZUGYAYsm/ln9hfZ1kqgCfaOBI
IgLuWNW0+CKQKDqsQOOcTfQ=
=wFC6
-----END PGP SIGNATURE-----