Missing file reported after resolved removal conflict

[Martin von Gagern]

When updating a bound branch, and a file was removed in the master branch but modified in the working tree, a conflict occurs. When the conflict is resolved in such a way that the file is removed from the working tree as well, that file will be reported missing by bzr status, even if there was an update in between. Surprisingly, the actual file name reported missing will depend on the resolution method: --take-other will report the base name, but manual removal will cause the *.THIS file to be reported missing. I know of no way to actually resolve this spurious message from bzr status, which can be annoying on life projects.

Steps to reproduce, should make an easy blackbox test script (or rather two, I guess):

$ bzr init -q trunk
$ echo original > trunk/foo
$ bzr add -q trunk/foo
$ bzr commit -q -m first trunk
$ bzr checkout -q trunk one
$ bzr checkout -q trunk two
$ bzr rm -q trunk/foo
$ bzr ignore -d trunk foo
$ bzr commit -q -m second trunk
$ echo modified > one/foo
$ bzr update one
+N .bzrignore
RM foo => foo.THIS
Contents conflict in foo
1 conflicts encountered.
Updated to revision 2 of branch ${PWD}/trunk
$ rm one/foo.BASE one/foo.THIS
$ bzr resolve --all -d one
1 conflict(s) resolved, 0 remaining
$ bzr conflicts -d one
$ bzr status one
missing:
  foo.THIS
$ bzr update one
Tree is up to date at revision 2 of branch ${PWD}/trunk
$ bzr status one
missing:
  foo.THIS
$ echo modified > two/foo
$ bzr update two
+N .bzrignore
RM foo => foo.THIS
Contents conflict in foo
1 conflicts encountered.
Updated to revision 2 of branch ${PWD}/trunk
$ bzr resolve --take-other --all -d two
1 conflict(s) resolved, 0 remaining
$ bzr status two
missing:
  foo

[Martin von Gagern (gagern)]

Attached branch has test scripts exposing this issue. I don't intend to continue work on the actual issue itself any time soon, so if someone else does, please consider using that branch as a basis, and take it from there.

[Martin von Gagern (gagern)]

I found a way to deal with this problem: "bzr revert" on the named file will restore the output of "bzr status". I still believe that this shouldn't be needed.

I also found another detail: recreating the file after the resolve will cause it to be listed as added instead of missing. I've included my expectation for this case in the attached branch as well.

[Vincent Ladeuil (vila)]

'bzr resolve --all' is evil, it only get rid of the conflicts and remove the associated helpers (.BASE, .THIS, .OTHER or whatever).

The really evil part is that 'bzr resolve --all --take-other' does what you expect: resolve the conflict by taking the 'OTHER' version.

This is related to bug #344013 and bug #389396 and there is also a FIXME in bzrlib/conflicts.py (wrongly mentioning bug 383396, that's a typo).

This bug is not really a duplicate so I leave it alone.

[John A Meinel (jameinel)]

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

On 10/4/2011 4:59 PM, Vincent Ladeuil wrote:
> 'bzr resolve --all' is evil, it only get rid of the conflicts and
> remove the associated helpers (.BASE, .THIS, .OTHER or whatever).
>
> The really evil part is that 'bzr resolve --all --take-other' does
> what you expect: resolve the conflict by taking the 'OTHER'
> version.
>
> This is related to bug #344013 and bug #389396 and there is also a
> FIXME in bzrlib/conflicts.py (wrongly mentioning bug 383396, that's
> a typo).
>
> This bug is not really a duplicate so I leave it alone.

The issue is that 'bzr resolve' was originally designed as a "mark
this as resolved".

It needed 'bzr resolve --all' so that you wouldn't have to specify
each file when you fixed 10 files.

It then grew the ability to notice what was resolved and what wasn't,
so you could just say "bzr resolve".

It then grew the ability to take an action. So instead of being bzr
'mark-resolved' it suddenly became bzr 'help-me-resolve-the-conflict'.

I feel like we really need to create 2 separate commands. It is
possible the original intent should be the one renamed. (bzr
mark-resolved, bzr resolved, etc.)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6MjlEACgkQJdeBCYSNAAMSVwCgxfAT8851wGkQvTX+BtKdPkQj
umkAn2456Vf1ra400q1j+BOnn5xNBQmJ
=UdNl
-----END PGP SIGNATURE-----

[Martin von Gagern (gagern)]

On 05.10.2011 19:05, John A Meinel wrote:
> The issue is that 'bzr resolve' was originally designed as a "mark
> this as resolved".
>
> It needed 'bzr resolve --all' so that you wouldn't have to specify
> each file when you fixed 10 files.
>
> It then grew the ability to notice what was resolved and what wasn't,
> so you could just say "bzr resolve".
>
> It then grew the ability to take an action. So instead of being bzr
> 'mark-resolved' it suddenly became bzr 'help-me-resolve-the-conflict'.
>
> I feel like we really need to create 2 separate commands. It is
> possible the original intent should be the one renamed. (bzr
> mark-resolved, bzr resolved, etc.)

But notice that this bug here can be reproduced using the second
generation of the ancestry you sketched above: it uses --all so you
don't have to name the conflicting files individually, but it apart from
that, it can be reproduced with both the take-action and the flag-only
version of the command.

But as you mention the many different possible invocations: the
first generation style of naming the file to resolve gives the same
results as described in this report. The third generation version using
no arguments or options will report "0 conflicts auto-resolved." which
is the first useful statement in all of this. "bzr resolve --done
tree/foo" doesn't work either, so it's the mark-resolved which is broken.