Error during merge: No final name for trans_id 'new-70'

[Aaron Bentley]

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

On 12-09-18 02:33 PM, David Engster wrote:
> Aaron Bentley writes:
>> On 12-09-17 04:04 PM, David Engster wrote:
>>> bzr: ERROR: No final name for trans_id 'new-70' file-id: None
>>> root trans-id: 'new-0'
>>> 
>>> The offending commit in 'trunk' which is causing this error is 
>>> rev. 8235, which is a very large merge from another branch and 
>>> which surely leads to a criss-cross with many conflicts, but I 
>>> cannot do anything about that now, hence I'd appreciate any
>>> hints on how to deal with this error.
> 
> [...]
> 
>> You can fix this by restoring
>> obsolete/lisp/cedet/semantic/wisent, which you can do like so:
>> 
>> bzr revert -r 8184 obsolete/lisp/cedet/semantic/wisent/ bzr
>> resolve --all bzr commit -m "Restored directory"
>> 
>> Merge will then work, and you can delete the directory
>> afterward.
> 
> Aaron,
> 
> Thank you so much for your help! Everything's working fine now.
> 
>> The error you are getting is a bug in bzr.  This situation
>> should produce a conflict, not an error.
> 
> Actually, I was unsure about these kind of conflicts for quite
> some time. Say I have a change in 'trunk' to the file 'foo.txt'
> which is removed in 'to-emacs'. During the above merge I get a
> conflict for 'foo.txt', which I can resolve in two ways: Either
> use
> 
> bzr revert foo.txt
> 
> or
> 
> bzr resolve --take-this foo.txt
> 
> Are those two equivalent, or should I prefer one over the other?

They are equivalent in this situation.  The big difference between
"revert" and "resolve --take-this" is that resolve will only affect
files that are conflicted, so "bzr resolve --take-this" will generally
be safer, even with no arguments.

> Also, it would be very handy if bzr could resolve these types of 
> conflicts automatically. Can bzr automatically ignore changes for
> files which are removed in the target branch?

No, but you could certainly extend resolve or write a plugin to clean
it up afterward.

> As you may have seen, this situation is occurring very often in the
> above merge, since 'to-emacs' has many files from 'trunk' removed,
> so this would save me quite some time (I will have to do these
> kinds of merges regularly in the future...).

You could also delete the files from trunk before merging.

Aaron

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBYxksACgkQ0F+nu1YWqI0+tgCbBrzsKyIJn3q0PdwbJIYrixf/
dk0An36HXV58up24lpXTaeAsR65ILrZ7
=w/Kv
-----END PGP SIGNATURE-----