bzr resolve --take-this or --take-other fails for PathConflict if a dir is deleted

[Vincent Ladeuil]

One more bug uncovered by writing more precise tests.

This also revealed that the PathConflict object may be created with a file_id atribute set to None which makes
it harder to implement resolve

[John A Meinel (jameinel)]

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

Vincent Ladeuil wrote:
> Public bug reported:
>
> One more bug uncovered by writing more precise tests.
>
> This also revealed that the PathConflict object may be created with a file_id atribute set to None which makes
> it harder to implement resolve
>
> ** Affects: bzr
> Importance: High
> Assignee: Vincent Ladeuil (vila)
> Status: Confirmed
>

Right, I believe it does so if it is trying to create a foo.OTHER and
finds a foo.OTHER already present.

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

iEYEARECAAYFAkuP4JoACgkQJdeBCYSNAAN1TACggKdLk7V8jVfoqSyyLRQ4AVne
zEgAn0gA2DUV2t9S25vsJdoHm0PTPFrD
=yB7e
-----END PGP SIGNATURE-----

[Vincent Ladeuil (vila)]

> Right, I believe it does so if it is trying to create a foo.OTHER and
> finds a foo.OTHER already present.

I wish it was :-(

The problem AIUI is that we don't handle PathConflict as we handle ContentConflict
when one side delete the item (file, dir, etc).

With ContentConflict, the deleted item is still available as .OTHER or .THIS whereas
for PathConflict the deleted item is nowhere to be seen, hence, the file-id is not
even valid anymore in the working tree.

[Vincent Ladeuil (vila)]

See attached script for the various cases.