iter_merge_sorted_revisions fails on doubly-stacked branch
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
Medium
|
Unassigned |
Bug Description
If a branch is stacked on a branch which is itself stacked, iter_merge_
mwh@grond:
Created a standalone tree (format: 2a)
mwh@grond:
bzr: ERROR: no such option: -d
mwh@grond:
bzr: warning: The commit message is a file name: ".".
(use --file "." to take commit message from that file)
Committing to: /home/mwh/
You need a passphrase to unlock the secret key for
user: "Michael Hudson <email address hidden>"
1024-bit DSA key, ID 6EC0EE48, created 2007-09-28
Committed revision 1.
mwh@grond:
Created new stacked branch referring to file://
mwh@grond:
bzr: ERROR: no such option: -d
mwh@grond:
Created new stacked branch referring to file://
mwh@grond:
mwh@grond:top$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> b = bzrlib.
>>> list(b.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<string>", line 4, in iter_merge_
File "/usr/lib/
last_key)
File "_known_
File "_known_
KeyError: ('<email address hidden>',)
>>>
If the stackings are non-trivial (i.e. there is a revision in middle's repo that is not present in base's repo), it doesn't crash, but something's not right either. I'll attach a script that reproduces this.
Changed in bzr: | |
importance: | Undecided → High |
status: | New → Confirmed |
tags: | added: stacking |
Changed in bzr: | |
importance: | High → Medium |
tags: | added: check-for-breezy |
Here's a shell script that reproduces the problem. Look at the difference in the output of 'log --include-merges' between top and top-stacked.