cherrypicking merge fails: No final name for trans_id 'new-1'

Bug #364305 reported by Frits Jalvingh on 2009-04-20
56
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Bazaar
High
Vincent Ladeuil

Bug Description

I'm trying to cherrypick a change from a different, related branch into another one:

jal@pyramides:~/bzrws/vp-lite-split/domui$ bzr merge -r 1102..1103 /home/jal/itrisbzr/vp-fix-upload
 M to.etc.domui/src/to/etc/domui/server/DomApplication.java
 M to.etc.domui/src/to/etc/domui/server/RequestContextImpl.java
 M to.etc.domui/src/to/etc/domui/util/upload/UploadParser.java
/usr/lib/python2.6/dist-packages/bzrlib/ui/__init__.py:91: UserWarning: ProgressTask(0/2, msg='Apply phase') is not the active task ProgressTask(None/None, msg='')
  % (task, self._task_stack[-1]))
/usr/lib/python2.6/dist-packages/bzrlib/ui/__init__.py:91: UserWarning: ProgressTask(2/3, msg='Merge phase') is not the active task ProgressTask(None/None, msg='')
  % (task, self._task_stack[-1]))
bzr: ERROR: No final name for trans_id 'new-1'
file-id: None
root trans-id: 'new-0'

I use bzr from Jaunty, version=1.13.1-1:
jal@pyramides:~/bzrws/vp-lite-split/domui$ bzr version
Bazaar (bzr) 1.13.1
  Python interpreter: /usr/bin/python 2.6.2
  Python standard library: /usr/lib/python2.6
  bzrlib: /usr/lib/python2.6/dist-packages/bzrlib
  Bazaar configuration: /home/jal/.bazaar
  Bazaar log file: /home/jal/.bzr.log

Frits Jalvingh (fjalvingh) wrote :

Well, it looks like bzr hates me today. I again got this error, this time with a normal merge:

jal@pyramides:~/work/vp-lite-trunk$ bzr merge ~/bzrws/vp-lite-split/shared
+N to.etc.server/src/to/etc/server/servicer/IServiceAuthenticator.java
 M to.etc.alg/src/to/etc/util/ClassUtil.java
 M to.etc.alg/src/to/etc/util/StringTool.java
 M to.etc.alg/src/to/etc/util/WrappedException.java
 M to.etc.db/src/to/etc/dbpool/PreparedStatementProxy.java
 M to.etc.db/src/to/etc/dbpool/StatementProxy.java
 M to.etc.server/src/to/etc/server/injector/RequestRetrieverProvider.java
 M to.etc.server/src/to/etc/server/servicer/AjaxServlet.java
 M to.etc.server/src/to/etc/server/servicer/ServiceCaller.java
 M to.etc.server/src/to/etc/server/servicer/ServiceCallerCallback.java
 M to.etc.server/src/to/etc/server/servicer/ServiceServerContext.java
/usr/lib/python2.6/dist-packages/bzrlib/ui/__init__.py:91: UserWarning: ProgressTask(0/2, msg='Apply phase') is not the active task ProgressTask(None/None, msg='')
  % (task, self._task_stack[-1]))
/usr/lib/python2.6/dist-packages/bzrlib/ui/__init__.py:91: UserWarning: ProgressTask(2/3, msg='Merge phase') is not the active task ProgressTask(None/None, msg='')
  % (task, self._task_stack[-1]))
bzr: ERROR: No final name for trans_id 'new-1'
file-id: None
root trans-id: 'new-0'

This is rather bad as this is quite an important thing to get merged. Any idea why this occurs?

Paul McCullagh (paul-mccullagh) wrote :

I know how to repeat this bug.

Please let me know if I should give details.

Martin Pool (mbp) wrote :

Aaron, do you know what's going on here?

Changed in bzr:
assignee: nobody → Aaron Bentley (abentley)
Frits Jalvingh (fjalvingh) wrote :

Paul, do you know what causes this error to occur? I mean, I can also repeat the problem sadly enough because merging these two branches is impossible. But I have no idea what operations cause this.

Frits Jalvingh (fjalvingh) wrote :

For extra info: merging the other way round does work!? The error occurs when I merge repository 'shared' INTO repository 'domUI', but merging 'domUI' into 'shared' works. It results in another oddity though: if I commit that and pull the result back into the original 'domUI' I get bug 282947. No idea whether these are related, just adding info.

Kristian Nielsen (knielsen) wrote :

I filed a new bug 375898 for a possibly related problem. I decided to file a new one since that has exact steps to reproduce, and it is not 100% clear that the problem is the same.

Paul McCullagh (paul-mccullagh) wrote :

Hi Fritz,

No, unfortunately I do not know which operation is actually causing this problem. I am working together with Kristian on this, and he has now reported "our version" of the bug here: bug 375898.

We do a whole series of operations to merge 2 repositories, so I am not sure where things go wrong.

Frits Jalvingh (fjalvingh) wrote :

Kristian: thanks for the detailed report! Your use case is /exactly/ the same as mine: it is a base project (sharedlibs) which is merged-with-history into a bigger project (domUI), including history like yours. With the same idea: allowing repeated merges of the base repository in the bigger project.

Robert Collins (lifeless) wrote :

Looks like a dup with bug 375898 to me. Aaron, did you have any comments?

Changed in bzr:
importance: Undecided → Medium
status: New → Triaged
Frits Jalvingh (fjalvingh) wrote :

Still present in 1.16. I now cannot merge any of my branches anymore meaning I effectively do not use bzr anymore.

I am trying to find out what goes wrong and will post progress here, I hope that gets some response from people that actually know how this stuff works.....

Background: I have a shared project repository (domUI) which is repeatedly merged into a master tree (vp-trunk). The first merge was done using a merge with full history of the domUI trunk. When I try to merge again we get this error. This is not a cherrypicking merge! The failing merge I am debugging has the following changes:

+N to.etc.webapp.core/src/to/etc/webapp/query/QRestrictionsBase.java
+N to.etc.webapp.core/src/to/etc/webapp/query/QSelectedItem.java
+N to.etc.webapp.core/src/to/etc/webapp/query/QSelection.java
 M to.etc.domui.hibutil/src/to/etc/domui/hibernate/model/CriteriaCreatingVisitor.java
 M to.etc.domui.pages/src/to/etc/domui/pages/generic/BasicListPage.java
 M to.etc.domui/src/to/etc/domui/component/input/LookupInput.java
RM to.etc.domui/src/to/etc/domui/trouble/CodeException.java => to.etc.webapp.core/src/to/etc/webapp/nls/CodeException.java
 M to.etc.webapp.core/src/to/etc/webapp/query/QCriteria.java
 M to.etc.webapp.core/src/to/etc/webapp/query/QMultiNode.java
 M to.etc.webapp.core/src/to/etc/webapp/query/QNodeVisitor.java
 M to.etc.webapp.core/src/to/etc/webapp/query/QNodeVisitorBase.java
-D to.etc.webapp.core/src/to/etc/webapp/query/QProjection.java
 M to.etc.webapp.core/src/to/etc/webapp/query/QRestriction.java

It looks like discovering changes goes OK since a merge --preview works properly.

So far I discovered the following by fuzzing around in transform.py:

The id "new-1" is assigned to "tree_root-20090331215929-42is8ly6zvj4rr4a-1" in "trans_id_file_id". This tree root name is the tree root in the domUI repository (i.e. the source of the merge).

The exception gets thrown in "final_name", because neither self._new_name nor self._tree_id_paths contains 'new-1' as a key. The values present in self._new_name are: {'new-16': 'QSelection.java', 'new-6': u'CodeException.java', 'new-15': 'QSelectedItem.java', 'new-13': 'QRestrictionsBase.java', 'new-2': '.bzrignore'}. The _tree_id_paths array contains some subset of files and directories?

Assigning the ID to the tree is done in merge.py, _compute_transform. The entry for the tree node reads:tree_root-20090331215929-42is8ly6zvj4rr4a-1 False (None, None, None) ('', '', None)

Frits Jalvingh (fjalvingh) wrote :

I added the following as debug test to final_name in transform.py:
    def final_name(self, trans_id):
        """Determine the final filename, after all changes are applied."""
        if trans_id == "new-1":
            self._tree_id_paths[trans_id] = ROOT_PARENT
            return ROOT_PARENT

(of course this is not a "fix")

This allows the merge to complete succesfully, and I can commit that change without problems. It seems like there's trouble locating a "target" for the source tree root? Should the 'transform' find a new location for a tree root somehow?

Frits Jalvingh (fjalvingh) wrote :

Just for info: I just retried with bzr-1.18rc1 on a --2a format repo that was fully new. The initial merge of the independent branch goes OK; all subsequent merges with the same branch still fail with the same error:
jal@mabillon:~/nbzr/vp-m$ bzr merge ../domui-trunk/
-D to.etc.domui/src/to/etc/domui/parts/ImagePartBase.java
 M to.etc.domui/src/to/etc/domui/server/ReloadingContextMaker.java
R to.etc.domui/src/to/etc/domui/server/logging.properties => to.etc.domui/src/to/etc/domui/server/oldlogging.properties
/home/jal/bzr-1.18rc1/bzrlib/ui/__init__.py:148: UserWarning: ProgressTask(0/2, msg='Apply phase') is not the active task ProgressTask(None/None, msg='')
  % (task, self._task_stack[-1]))
/home/jal/bzr-1.18rc1/bzrlib/ui/__init__.py:148: UserWarning: ProgressTask(2/3, msg='Merge phase') is not the active task ProgressTask(None/None, msg='')
  % (task, self._task_stack[-1]))
bzr: ERROR: No final name for trans_id 'new-5'
file-id: None
root trans-id: 'new-0'

Fran Boon (flavour) wrote :

I hit the same error with Bzr-1.18 on Win32.
I think I know why it occurred & hence managed to redo the operation succesfully:

I refused a change for creating a new folder.
I then accepted a change for creating a new file in that folder.

This makes sense, but obviously catching this error more gracefully would be better still :)

F

Andrew Schulman (andrex) wrote :

Is there any progress on this? I'm also affected by it, and as Fritz wrote almost 6 months ago, it's a complete show-stopper. It's hard for me to use bzr at all when I can't merge. Is there a workaround? Thanks, Andrew.

Andrew Schulman (andrex) wrote :

Forgot to mention that I have this problem in bzr 2.0.3, with a 2a-format repository. My use case is identical to Frits' in #8.

Kristian Nielsen (knielsen) wrote :

I verified that this still occurs with bzr 2.0.3:

$ bzr --version
Bazaar (bzr) 2.0.3
  Python interpreter: /usr/bin/python 2.5.2
  Python standard library: /usr/lib/python2.5
  Platform: Linux-2.6.27.9-kn-x86_64-with-debian-lenny-sid
  bzrlib: /usr/lib/python2.5/site-packages/bzrlib
  Bazaar configuration: /home/knielsen/.bazaar
  Bazaar log file: /home/knielsen/.bzr.log

Copyright 2005, 2006, 2007, 2008, 2009 Canonical Ltd.
http://bazaar-vcs.org/

bzr comes with ABSOLUTELY NO WARRANTY. bzr is free software, and
you may use, modify and redistribute it under the terms of the GNU
General Public License version 2 or later.

$ bzr branch 'lp:~knielsen/maria/mariadb-5.1-pbxt-merge-take2'
Branched 2696 revision(s).
$ bzr branch '-rrevid:<email address hidden>' lp:pbxt merge-source
Branched 609 revision(s).
$ cd mariadb-5.1-pbxt-merge-take2/
$ bzr co
$ bzr merge ../merge-source
+N mysql-test/suite/pbxt/r/type_varchar.result.OTHER
+N mysql-test/suite/pbxt/t/type_varchar.test.OTHER
 M storage/pbxt/src/ha_pbxt.cc
Contents conflict in mysql-test/suite/pbxt/r/type_varchar.result
Contents conflict in mysql-test/suite/pbxt/t/type_varchar.test
/usr/lib/python2.5/site-packages/bzrlib/ui/__init__.py:148: UserWarning: ProgressTask(0/2, msg='Apply phase') is not the active task ProgressTask(None/None, msg='')
  % (task, self._task_stack[-1]))
/usr/lib/python2.5/site-packages/bzrlib/ui/__init__.py:148: UserWarning: ProgressTask(2/3, msg='Merge phase') is not the active task ProgressTask(None/None, msg='')
  % (task, self._task_stack[-1]))
bzr: ERROR: No final name for trans_id 'new-1'
file-id: None
root trans-id: 'new-0'

Martin Pool (mbp) wrote :

I don't think Aaron actually agreed to take this, so since we don't generally unilaterally assign bugs, I'm going to unassign it.

Changed in bzr:
importance: Medium → High
Martin Pool (mbp) on 2010-01-04
Changed in bzr:
assignee: Aaron Bentley (abentley) → nobody
John A Meinel (jameinel) wrote :

Note that this could be related to bug #494269

Frits Jalvingh (fjalvingh) wrote :

I was busy typing that in... I think so too.

Vasil Dimov (vasild) wrote :

I am hitting this with bzr 2.1.0 and with latest 2.2.0dev1.

Please fix this bug!

Keith Hellman (khellman) wrote :

I'm running bzr in debian testing:

ii bzr 2.0.4-1 easy to use distributed version control syst
ii bzr-rebase 0.5.4-1 Rebase plugin for Bazaar
ii bzr-svn 1.0.0-1 Bazaar plugin providing Subversion integrati
ii bzrtools 2.0.1-1 Collection of tools for bzr

and I'm being slapped by this bug as well (I think) but SLIGHTLY DIFFERENTLY, via shelve and unshelve:
1. I had two branches, a mainline and a bugfix branch.
2. I shelved my bugfix delta,
3. pulled, pushed, and merged my two branches into sync (I had made non-bug-related-but-good changes in the bugfix branch, and needed some changes from my mainline to simplify the bug investigation). All was fine.
4. When I tried to unshelve my bugfix delta, I got:

Unshelving changes with id "1".
bzr: ERROR: No final name for trans_id 'new-14'
file-id: 'fake-20081024121641-mkarq1czq498lhus-1'
root trans-id: 'new-0'

The only thing I can think of is that during one of my merges from mainline -> bugfix I got a warning about a delta in my working dir. Seemed strange at the time, bzr status revealed nothing, so I did a bzr ci --unchanged and then the merge worked.

The other component is that I had recently done some cherry picking of files from *very* previous trees --- like a year ago, at least 200 commits, definetly from different .bzr format (if that matters). In the process of the pull/push/merge, I noticed a VERY OLD
directory (happened to be called 'FAKE', note the file-id above...) --- I removed this correctly via bzr in one of my trees and merged the change across --- no errors, no warnings. Not sure if that little bit means anything, the occurance of 'fake' seems suspicious to my lay eye.

Sadly, although I make religious nightly backups, I've effectively lost a morning's worth of work because I can't get back my very tedious and targeted changes. I thought I was making headway on my own defect .... not any more :^(

On a happier note. BZR freakin' rocks --- I've had all of 2 serious issues in the past several years (this is one of them), I maintain over 15 repos, including home directories across multiple machines. Keep up the good work -- viva la BZR! I'm going to go try the only patch in this thread and see if that works...

Keith Hellman (khellman) wrote :

Clarification to my previous post: FAKE was a real, bzr controlled, directory a long time ago. I'm sure it was not somehow created by BZR --- it was at one time part of my project. I assume FAKE was accidentally rekindled by myself when I cherrypicked some old files.

Keith Hellman (khellman) wrote :

Hey, and look what I found: here is the message I got back from bzr when I made the --unchanged commit in order for the merge to succeed.

$ bzr ci -m "no changes" --unchanged
Committing to: /home/khellman/sbox/nph-broken-elements/
missing FAKE
Committed revision 300.

Sorry for the long-winded post --- goes to show how often I have to report bzr bugs.

Martin Pool (mbp) on 2010-03-18
Changed in bzr:
status: Triaged → Confirmed
Vincent Ladeuil (vila) wrote :

Replying to https://bugs.edge.launchpad.net/bzr/+bug/364305/comments/16, as a data point,
  bzr merge ../merge-source --preview

succeeds but the output contains:
Contents conflict in mysql-test/suite/pbxt/r/type_varchar.result
Contents conflict in mysql-test/suite/pbxt/t/type_varchar.test

=== added file 'mysql-test/suite/pbxt/r/type_varchar.result.OTHER'

and

=== added file 'mysql-test/suite/pbxt/t/type_varchar.test.OTHER'

William Chambers (bioselement) wrote :

Issue still exists and is a major show stopper.

Martin Pool (mbp) on 2010-04-12
tags: added: merge
Vincent Ladeuil (vila) wrote :

@William, none of the comments give a precise recipe to reproduce, but this may be a dupe of bug #375898, can you try the fix in the associated branch and tell us if it fixed your problem too ?

Changed in bzr:
assignee: nobody → Vincent Ladeuil (vila)
status: Confirmed → In Progress
William Chambers (bioselement) wrote :

@Vincent, I tried the fix and it seems to have worked just fine. From what I can tell, this is indeed a dupe of bug #375898.

Vincent Ladeuil (vila) on 2010-04-12
Changed in bzr:
milestone: none → 2.0.6
status: In Progress → Fix Released
Frits Jalvingh (fjalvingh) wrote :
Download full text (3.8 KiB)

Sorry, but it looks like this is still unresolved. I tried to recreate the same repository structures as before by merging two earlier unrelated repositories. That initial merge worked OK. But when I then merge an updated branch into the combined branch I again get a similar error:

jal@odeon:~/bzr/t-merge$ bzr merge ../domui-trunk
Warning: criss-cross merge encountered. See bzr help criss-cross.
bzr: ERROR: No final name for trans_id 'new-211'
file-id: None
root trans-id: 'new-0'

The .bzr.log file states:

Sat 2010-09-04 17:54:12 +0200
0.029 bazaar version: 2.2.0
0.030 bzr arguments: [u'merge', u'../domui-trunk']
0.040 looking for plugins in /home/jal/.bazaar/plugins
0.080 looking for plugins in /usr/lib/python2.6/dist-packages/bzrlib/plugins
0.080 Plugin name qbzr already loaded
0.086 encoding stdout as sys.stdout encoding 'UTF-8'
0.107 opening working tree '/home/jal/bzr/t-merge'
[ 4337] 2010-09-04 17:54:13.753 WARNING: Warning: criss-cross merge encountered. See bzr help criss-cross.
0.776 Criss-cross lcas: set(['<email address hidden>', '<email address hidden>'])
0.824 Base revid: '<email address hidden>'
1.740 Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 911, in exception_to_return_code
    return the_callable(*args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1111, in run_bzr
    ret = run(*run_argv)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 689, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 704, in run
    return self._operation.run_simple(*args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 135, in run_simple
    self.cleanups, self.func, *args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 165, in _do_with_cleanups
    result = func(*args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/builtins.py", line 3882, in run
    verified)
  File "/usr/lib/python2.6/dist-packages/bzrlib/builtins.py", line 3901, in _do_merge
    conflict_count = merger.do_merge()
  File "/usr/lib/python2.6/dist-packages/bzrlib/merge.py", line 704, in do_merge
    merge = operation.run_simple()
  File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 135, in run_simple
    self.cleanups, self.func, *args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 165, in _do_with_cleanups
    result = func(*args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/merge.py", line 675, in _do_merge_to
    merge.do_merge()
  File "/usr/lib/python2.6/dist-packages/bzrlib/merge.py", line 814, in do_merge
    operation.run()
  File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 131, in run
    self.cleanups, self.func, self, *args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 165, in _do_with_cleanups
 ...

Read more...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers