'No final name for trans_id' during merge

[John Arbash Meinel]

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

On 2013-05-29 20:27, David Engster wrote:
> I was already bitten by this bug once, see
> 
> http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/74586
>
>  and now it has happened again; I'm getting this error during
> merge:
> 
> bzr: ERROR: No final name for trans_id 'new-247' file-id: None root
> trans-id: 'new-0'
> 
> I'm guessing it is again because of changes on files which are
> deleted in the other branch. You should be able to reproduce this
> by doing

I'm digging into this a bit, I can at least give the context for what
is triggering this. I don't (yet) have an answer for a fix.

Specifically, the 'new-247' relates to

trunk: /obsolete/lisp/eieio/
which is referred to as the parent of
trunk: /obsolete/lisp/eieio/eieio-doc.el

(and a few other files).

In THIS, the directory is deleted. In BASE the file is located at
lisp/eieio/eieio-doc.el

The issue appears to be a conflict between renaming a file into a
directory, when both the file and the directory has been deleted in
the target branch.

bzr init-repo --trees delete-bug
cd delete-bug
bzr init base
mkdir base/a_dir
touch base/a_file
bzr add base
bzr commit -m "base creates" base
bzr branch base this
bzr branch base other
bzr mv other/a_file other/a_dir
bzr commit -m "other renames" other
bzr rm this/a_file this/a_dir
bzr commit -m "this deletes" this
cd this
bzr merge ../other

bzr: ERROR: No final name for trans_id 'new-2'
file-id: None
root trans-id: 'new-0'


If the file isn't deleted, but the directory is, bzr will see a
conflict with a deleted directory and a rename, and restore the
directory and apply the rename.

bzr init-repo --trees only-dir
cd only-dir
bzr init base
mkdir base/a_dir
touch base/a_file
bzr add base
bzr commit -m "base creates" base
bzr branch base this
bzr branch base other
bzr mv other/a_file other/a_dir
bzr commit -m "other renames" other
bzr rm this/a_dir
bzr commit -m "this deletes" this
cd this
bzr merge ../other

$ bzr st
added:
  a_dir/
renamed:
  a_file => a_dir/a_file
conflicts:
  Conflict adding files to a_dir.  Created directory.
  Conflict because a_dir is not versioned, but has versioned children.
 Versioned directory.
pending merge tips: (use -v to see all merge revisions)
  John Arbash Meinel 2013-05-30 other renames


If you delete the file but not the directory, you get a path conflict:
bzr init-repo --trees only-file
cd only-file
bzr init base
mkdir base/a_dir
touch base/a_file
bzr add base
bzr commit -m "base creates" base
bzr branch base this
bzr branch base other
bzr mv other/a_file other/a_dir
bzr commit -m "other renames" other
bzr rm this/a_file
bzr commit -m "this deletes" this
cd this
bzr merge ../other


Path conflict: <deleted> / a_dir/a_file
1 conflicts encountered.



The other reason that you are encountering this, is because you are
probably ending up with a very old BASE tree. This is likely because
you are using to-emacs as an integration branch (merging feature
branches), while also merging the other integration branch (trunk). If
you both merge multiple branches, and then you merge trunk, we can't
select any of the revisions as dominant over the multiple feature
branches (for example, if there were conflicts, each of you could have
resolved them in opposite ways).

So we have to go to an older base. In this case, it is a base which
has not yet moved eieio-doc.el into obsoleted, so you end up with a
rename into a directory of a bunch of stuff that you've deleted.
(Would you have still wanted to delete it if it was renamed instead?
As a human I can say yeah, you probably wanted it all gone, but all
bases point to it being active and just being renamed, and the target
is marking it as deleted. The word 'obsoleted' doesn't mean anything
special to bzr.)



As for a fix for this... well a workaround would be to:

cd to-emacs
# Restore the obsolete directory to existence
bzr revert -r -1:../trunk obsolete
# Merge the actual trunk
bzr merge ../trunk --force [--weave]
# Deal with the 100 or so conflicts
bzr resolve
# Remove obsolete again
bzr rm --no-backup obsolete
bzr commit -m "Merged trunk, did good stuff today"

Is there a bug number for this?

Offhand, I think the code that does:
        conflicts.extend(self._unversioned_parents(by_parent))

Probably needs to handle when target is deleted, but we still have a
parent we are trying to restore. Or at least, have some way of
describing all of the path conflicts of things that have been renamed
in OTHER but deleted in THIS.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlGm1G8ACgkQJdeBCYSNAANyKgCgyr8lT+qcd5K1MrlEO8Uqwjmd
MsAAniH0/G6e382SxIHZgiACWU8ft5xM
=utGo
-----END PGP SIGNATURE-----