bzr merge fails if deleted contents differ

[Aaron Bentley]

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

John A Meinel wrote:
> Aaron Bentley wrote:
> 
> Can you "differ in BASE and OTHER" but not exist in BASE? 

Yeah.  It means the difference between BASE and OTHER is that it doesn't
exist in BASE :-)

> I think you
> mean "differ in BASE and OTHER but does not exist in THIS". Which was
> the earlier discussion (because even the directory may not exist).

Actually, I meant "differ in BASE and THIS but doesn't exist in
OTHER".

> I'm running into the other problem now, though. Where a file differs
> between BASE and OTHER, but has been deleted in THIS. Can we just create
> file.BASE and file.OTHER if the directory exists? Obviously if the
> directory is different we would have to do something like creating a
> conflict directory. (Since we don't want to recreate the deleted dir).

For symmetry with the fix for yesterday's issue, I think we do want to
create the deleted directory, but not version it.

> This is happening in similar trees, basically with my
> newformat-transport branch, I manually added a file (and made sure its
> file-id came across) because the merge had failed. Then bzr.newformat
> merged with integration, which also brought in that file, but a slightly
> newer version.
> 
> $ bzr merge /srv/bzr/public/mirrors/bzr.newformat/
> bzr: ERROR: The file bzrlib/remotebranch.py was modified, but does not
> exist in this tree

That's definitely the wrong error.  If the file IDs are the same, then
remotebranch.py exists in both newformat-transport and bzr.newformat.
You should be getting a new_contents_conflict.

> It would be nice to have a "merge --continue-on-errors" flag.

I really don't like that idea.  It's like saying you'd like a program to
re-run itself if it segfaults.  Any kind of conflict can be handled, we
just need to decide how.  I don't think ignoring conflicts is a
reasonable answer.

> Because
> some of the conflicts are stuff that I would delete anyway, and I just
> want to get all the other changes merged.

I just want a plan for how to handle conflicts.  If we had one, I'd
probably have implemented it by now.

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

iD8DBQFDPCdu0F+nu1YWqI0RArFTAJ0W2CDtr3puWwvZdNxJg/7s7xF6WgCfdKsO
DAYniQ8Exo4n6lwWwW/CMIw=
=lQzM
-----END PGP SIGNATURE-----