Merge conflict: "2 conflicts encountered" but no "bzr conflicts" output

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

Brad Bollenbach wrote:
| I'm guessing then that the conflicts and the WARNINGs are related, but
| this is confusing.

There were no textual conflicts, just tree-shape conflicts, which are
reported as WARNINGs, like other conflicts. The conflicts were: merge
wanted to remove two directories, but your working copy had files that
it didn't expect to find there. These conflicts were handled by merely
unversioning the directories, instead of deleting them as usual.

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

iD8DBQFDgk5C0F+nu1YWqI0RAm4BAJ0fA1FjIsuwzIc2HMs0YyMOdGov+wCdH7Zk
g7gNsAPA5u2pkDTYsRrNa58=
=TTkm
-----END PGP SIGNATURE-----

On 21-Nov-05, at 5:48 PM, Aaron Bentley wrote:

> Public bug report changed:
> https://launchpad.net/malone/bugs/4700
>
> Comment:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Brad Bollenbach wrote:
> | I'm guessing then that the conflicts and the WARNINGs are
> related, but
> | this is confusing.
>
> There were no textual conflicts, just tree-shape conflicts, which are
> reported as WARNINGs, like other conflicts. The conflicts were: merge
> wanted to remove two directories, but your working copy had files that
> it didn't expect to find there. These conflicts were handled by
> merely
> unversioning the directories, instead of deleting them as usual.

Any thoughts on how this information can be presented in the UI?
Here's an idea (that probably doesn't make complete sense, because I
don't have the context of being a bazaar developer):

---
$ bzr conflicts
bazaar wanted to remove the following directories:

foo/bar
foo/bar/baz

but couldn't, because these directories were not empty. (Perhaps they
contain ignored files? See "bzr ignored".)

To resolve this conflict, you could try examining the contents of
these directories and, if they contain files that you no longer need,
you can probably safely remove these directories manually (e.g. "rm -
r foo/bar".)
---

http://headrush.typepad.com/creating_passionate_users/2005/10/
making_happy_us.html

I'm still working my way through the "I suck" phase with bazaar. :)

Cheers,

--
Brad Bollenbach

Here's another example of this strange behaviour:

bradb@oxygen:~/canonical/malone-bzr-integration $ bzr merge ../launchpad-upstream/
Inventory ok.
bzr: WARNING: Conflict adding files to lib/canonical/lp/z3batching. Not deleting.
1 conflicts encountered.
bradb@oxygen:~/canonical/malone-bzr-integration $ bzr conflicts
bradb@oxygen:~/canonical/malone-bzr-integration $

My mental model tells me that, if N conflicts are encountered, bzr conflicts should show N conflicted files.

Robert says the "Conflict adding files to lib/canonical/lp/z3batching." is because z3batching was deleted by the branch Brad was merging in, but there are .pyc files in the directory in the working tree.

This is worse than the previous "Directory $foo not removed because it is not empty" message, which is more like what I would expect (regardless of how "bzr conflicts" subsequently reports this or not). "Conflict adding files" is surprising, because the user hasn't added any files to that directory, and the branch merged from is *deleting* that directory, so it's a mystery what files it thinks are being added, especially as bzr doesn't say which files it's referring to, and there's no obvious way to find out.

Anyway, I think I would like bzr conflicts to inform me of non-textual conflicts, even if I don't need to explicitly resolve them to commit. After a large merge, the output of "bzr st" is quite large, so I really want to use "bzr conflicts" as a way to see where the potential problems with this merge are, as a sort of task list of things to look at (and probably resolve) before I commit. I wouldn't want to miss thinking about a tree-shape conflict because it's only listed as a one-off warning. I don't care about this as much as having the conflict be clearly described, though.

OK so the essence of the bug is that bzr conflicts should remember and report non-textual conflicts.

I think Aaron's new conflict-remembering code may be able to accomodate this; I don't know if it's done yet.

I do believe the latest TreeTransform code should handle this.
If there is still an problem, this bug can be re-opened. Especially if a simple set of steps can be demonstrated.