Assertion error in delta.py (_compare_trees)
marius at pov.lt
Thu Mar 1 19:53:49 GMT 2007
On Thu, Mar 01, 2007 at 11:56:26AM -0600, John Arbash Meinel wrote:
> Marius Gedminas wrote:
> > On Thu, Mar 01, 2007 at 02:24:51AM +0200, Marius Gedminas wrote:
> > ...
> >> File "/home/mg/src/bzr.dev/bzrlib/inventory.py", line 212, in find_previous_heads
> >> assert candidates[ie.revision] == ie
> >> AssertionError
> > 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).
> 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?
They are, now: http://mg.pov.lt/fbreader/tmp/
Short history (I hope I remember it correctly):
upstream: apparently I changed some symlinks to files in this
branch, then comitted, but bzr (whichever version it was) ignored and
did not commit those changes.
toc-marks: branched from upstream, committed some changes on top
upstream: committed the file type changes with bzr 0.15.0dev0
At this point I can cd into toc-marks and bzr merge ../upstream, but
after that I cannot bzr commit (with the informative patch you
File "/home/mg/src/bzr.dev/bzrlib/inventory.py", line 212, in find_previous_heads
assert candidates[ie.revision] == ie, (
AssertionError: Mismatch between inventory records:
revision='mgedmin at b4net.lt-20060809170036-438b9093426de34f') !=
revision='mgedmin at b4net.lt-20060809170036-438b9093426de34f')
(You can ignore the other branches for now, although I first saw the
problem when I tried to bzr merge toc-marks into the mg branch and then
> 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.
I can reproduce it with this shell script. It requires that you have
both bzr 0.11 and 0.15 somewhere (change the alias definitions)
mkdir -p branch1
bzr11 init branch1
ln -s missing branch1/file1
bzr11 add branch1/file1
bzr11 ci branch1 -m "Add a symlink"
bzr11 ci branch1 -m "Try to convert a symlink to a directory" # <-- fails
bzr11 branch branch1 branch2
bzr15 ci branch1 -m "Convert a symlink to a directory"
(cd branch2 && bzr15 merge ../branch1)
bzr15 ci branch2 -m "Merge branch1" # <-- fails with AssertionError
BTW if I comment out the "bzr11 ci branch1 -m "Try to..."" line, I get the same
Give a man a computer program and you give him a headache, but teach him to
program computers and you give him the power to create headaches for others for
the rest of his life...
-- R. B. Forest
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070301/cf2996ac/attachment-0001.pgp
More information about the bazaar