bzr 1.16 blows up on upgrade or check
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Bazaar |
Invalid
|
Undecided
|
Unassigned | ||
Bug Description
When trying to upgrade a 1.9 format to 2a, I got a traceback, which is also triggered by running check.
It is *not* triggered by reconcile, and reconciling does nothing to fix it.
Traceback:
Traceback (most recent call last):
File "/usr/lib/
return the_callable(*args, **kwargs)
File "/usr/lib/
ret = run(*run_argv)
File "/usr/lib/
return self.run(
File "/usr/lib/
check_
File "/usr/lib/
result = repo.check()
File "/usr/lib/
result = unbound(self, *args, **kwargs)
File "/usr/lib/
return self._check(
File "/usr/lib/
result.check()
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
ie.check(self, rev_id, inv, tree)
File "/usr/lib/
self.
File "/usr/lib/
if (self.text_sha1 != tree._repositor
KeyError: ('wiki_
| John A Meinel (jameinel) wrote | #1 |
This at least looks like a case where the given text is actually missing.
So the inventory is referencing a (file, revision) key that is not present in the repository's text store.
reconcile doesn't "fail" because it can't do anything about a missing file.
A few possibilities present themselves
1) What is it about this inventory that caused us not to fetch the text. Certainly this sounds like a ghost issue, or one of the inventory bugs where a commit would claim a last-modified revision that the inventory itself did not claim. (So inventory for rev2 says the file was last modified in rev1, but the inventory in rev1 *doesn't* say that it was modified in rev1)
Note that the revision in question is from 200705, which means that it is likely to have been committed with a much older version of bzr. NEWS claims bzr 0.16 was released 2007-05-07, which was right after Dirstate was released (0.15) and IIRC 0.15 had a few dirstate bugs. I don't know that it would cause this, but potentially it could have.
2) We could try to artificially fill in the missing text from:
a) Another repository that might have that text already present
b) Look at the sha1, and see if we have any text with the same sha1 present.
3) Alternatively, we could try and rewrite the inventory to not reference that text. Instead, have it reference whatever a reasonable parent would reference. However, this potentially opens us up to having 2 inventories with different texts.
4) Versions of bzr ~>= 1.13 use a set-difference algorithm to determine what texts to send, so should be copy referenced texts, even if we aren't copying the revision that it claimed to be introduced in.
Versions just prior to that did not. (they only copied texts that were exactly referenced by the given revision).
So it is possible that a bzr circa 0.15/16 created a bad inventory, and a bzr circa 1.11/12 failed to copy the referenced text. So at this point, you really don't have that text present.