Assertion error in delta.py (_compare_trees)
John Arbash Meinel
john at arbash-meinel.com
Thu Mar 1 17:56:26 GMT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Marius Gedminas wrote:
> On Thu, Mar 01, 2007 at 02:24:51AM +0200, Marius Gedminas wrote:
>> The saga continues: bzr 0.15.0dev0 found a bunch of uncommitted changes
>> in my 'upstream' branch. Naturally, I committed them. I then attempted
>> to merge upstream into the new branch I created today (with bzr 0.11).
>> bzr merge succeeds, but then bzr commit barfs:
>> File "/home/mg/src/bzr.dev/bzrlib/inventory.py", line 212, in find_previous_heads
>> assert candidates[ie.revision] == ie
>> bzr 0.15.0dev0 on python 2.4.4.candidate.1 (linux2)
>> arguments: ['/home/mg/bin/bzr', 'ci']
> Any ideas? I'm kind of sitting here not knowing whether my existing
> branches are broken and whether I should start from scratch (I have
> cumulative diffs of all my changes, so I'd just lose some history).
> Marius Gedminas
Well, I'm not sure what is causing this problem. My best guess is that
you have one branch which thinks things should be a symlink, and another
which thinks they should be a file. But somehow they both have the same
'last-changed' revision. It seems like this shouldn't be possible, since
one of them should have a new last-changed when the file changed to a
Are these branches public?
As a quick inspection method, you can try to at least add a bit of
debugging to the assert line. Something like:
=== modified file 'bzrlib/inventory.py'
- --- bzrlib/inventory.py 2007-02-18 00:22:24 +0000
+++ bzrlib/inventory.py 2007-03-01 17:55:00 +0000
@@ -209,7 +209,9 @@
# must now be the same.
- - assert candidates[ie.revision] == ie
+ assert candidates[ie.revision] == ie, (
+ "Mismatch between inventory records:"
+ " %s != %s" % (candidates[ie.revision], ie))
# add this revision as a candidate.
candidates[ie.revision] = ie
If we can figure out why it is so unhappy, we can try to figure out the
easiest way to fix it.
One possibility is to just do "bzr rm $file; bzr add $file" for all of
the files that changed kind. That should prevent this assert from
triggering. Even if it isn't the "best" fix.
But it would be nice to be able to reproduce an error like this, so that
we can write up a test case, and fix it so it doesn't happen again.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar