[MERGE/RFC] Revert reporting #3707

Aaron Bentley aaron.bentley at utoronto.ca
Thu Jan 11 15:12:18 GMT 2007


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

John Arbash Meinel wrote:
> Aaron Bentley wrote:
>>>Well, as I noted in my previous email,
>>>
>>>
>>>>>> - they have no way to represent a 'kind' change
> 
> 
> Just add a 'K' in place of 'M', since Kind supersedes Modified.

I think that's not enough information.  We need to show what the
original kind was, and what the new kind was.  My format showed this by
using the same formatting as rename:

 K  name/ => name@

>>>>>> - they don't differentiate between 'renamed' and 'renamed and modified'.
> 
> 
> Actually, it does. I don't know if you saw the output but it was:
> % bzr st
> added:
>   b
> renamed:
>   b => c
> modified:
>   c
> % bzr status --short
> A  b
> R  b => c
> M  c
> 
> So if a file was renamed and modified it gets 2 lines.
> R  b => c # file was renamed to c
> M  c      # file c was also modified

Okay, so I'm wrong.  I think that this approach isn't very clear, though.

>>>>>> - they can't indicate file versioning operations separately from file
>>>>>>creation/deletion

> Well, I don't think it really should, 

People tended to freak out when revert deleted their files.  So I don't
want to make it look like revert has deleted their files when it hasn't.

But revert WILL delete files if doing so wouldn't lose data.

So I think it's important to differentiate between them.

> but maybe... I suppose 'bzr merge'
> or 'bzr revert' could indicate this, but I don't think 'bzr status' can
> without writing out more information.

Yes, if we want to accurately depict add, we'd need our basis info to
include the unversioned files.

With our current info, we would be able to distinguish between deletion
and removal, though.

> Certainly if I do 'bzr add X', that will always be an add without a
> create, since X already existed or you couldn't run add it. But in your
> logical model, that should probably be both an add plus a create.

There's an argument that if the file existed at commit time, it ought to
be "add without create", but if the file was created after the last
commit, it ought to be "add with create".  But I'd be happy to fudge
that case so we always show "add without create" in status.

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

iD8DBQFFplPS0F+nu1YWqI0RAgkYAJ9NBttP5MJ++2nZ7Mj9S5tORmYmkACePjbP
x6BJRTWdfUWh/Xg7nVLkm+g=
=/KEE
-----END PGP SIGNATURE-----



More information about the bazaar mailing list