check reports "Missing inventory {('TREE_ROOT'..." for trivial non-rich-root branch

Bug #416732 reported by Andrew Bennetts on 2009-08-21
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Bazaar
Critical
Robert Collins
2.0
Critical
Robert Collins

Bug Description

With current bzr.dev:

andrew@steerpike:/tmp$ bzr init --1.9 non-rr-test
Created a standalone tree (format: 1.9)
andrew@steerpike:/tmp$ cd non-rr-test/
andrew@steerpike:/tmp/non-rr-test$ bzr ci -m "Foo." --unchanged
Committing to: /tmp/non-rr-test/
Committed revision 1.
andrew@steerpike:/tmp/non-rr-test$ bzr check
Checking working tree at '/tmp/non-rr-test'.
Checking branch at 'file:///tmp/non-rr-test/'.
Checking repository at 'file:///tmp/non-rr-test/'.
checked repository <bzrlib.transport.local.LocalTransport url=file:///tmp/non-rr-test/> format <RepositoryFormatKnitPack6>
     1 revisions
     0 file-ids
Missing inventory {('TREE_ROOT', '<email address hidden>')}
checked branch file:///tmp/non-rr-test/ format Branch format 7

"bzr check" on a trivial, new branch should not be finding problems! Rich-root formats, like 2a, seem to be unaffected. My guess is that this is a bug in check on non-rich-root repositories (rather than a bug in what is stored in the repository that check discovers). Upgrading to 2a fixes the problem.

(There have been other reports that look like this problem, e.g. <https://lists.ubuntu.com/archives/bazaar/2009q3/061525.html>. I'm not sure if that is the same, or even related though.)

As this doesn't affect 2a branches (and is corrected by upgrading to 2a) I'm not targetting this to 2.0. But I'm still marking it as High as it seems pretty serious to me.

Related branches

Neil Martinsen-Burrell (nmb) wrote :

Respectfully, I think that this bug is Critical for releasing 2a as the default format. Check should not be spouting irrelevant errors in a properly-working upgrade process. A clean upgrade process is imperative for Bazaar's roll out of a new default format. As it is, rather than all check output being problems, some of the output is irrelevant and can safely be ignored (or so we think). Again, check is part of the upgrade process as described at http://doc.bazaar-vcs.org/bzr.dev-html/en/upgrade-guide/index.html and check has broken its commitment that "The working tree and branch checks will only give output if a problem is detected." As such, the upgrade process is broken and I don't think that 2a should be made the default until the upgrade process is working *right*.

(See https://lists.ubuntu.com/archives/bazaar/2009q3/061248.html for another example of the same problem.)

Andrew Bennetts wrote:

> As this doesn't affect 2a branches (and is corrected by upgrading to 2a)
> I'm not targetting this to 2.0. But I'm still marking it as High as it
> seems pretty serious to me.

And it is going to impact 2.0 support pretty heavily IMO, given the
Upgrade Guide tells users to run check prior to upgrading their
repositories and branches. Every single person doing that will

1. find the problem
2. try reconcile
3. see the problem is still there
4. get confused
5. maybe raise a bug or ping us on IRC.

So I think we definitely need to keep this in scope for 2.0.

Ian C.

Andrew Bennetts (spiv) wrote :

Fair enough. I'm targetting to 2.0.

Changed in bzr:
milestone: none → 2.0
Changed in bzr:
importance: High → Critical
Robert Collins (lifeless) wrote :

I intend to get this done first thing tomorrow, however I haven't made any actual progress towards it so far.

Changed in bzr:
assignee: nobody → Robert Collins (lifeless)
Martin Pool (mbp) on 2009-08-28
Changed in bzr:
status: Confirmed → In Progress

It's not much information, but I hope it proves useful:
1. Every revision seems to be reported, or at least: revno: 770 --> 771 errors, in one of my repositories.
2. I've tried bugtracing this a bit, and I've discovered that:
  if I set a breakpoint on: bzrlib/knit.py:1416 (absent_keys = keys.difference(set(positions))), on the third pass absent_keys will contain all revisions. (Or at least I assume that since it's a big list, most likely close to 770 (or 771) items.

I've tried to trace this bug, since I encounterd it a few days ago, but this is way out of my league. (With my very limited experience of python and bzr development.) I'm posting this here so it may possibly help others. (Can't blame a man for trying right? :P)

Changed in bzr:
status: In Progress → Fix Committed
Martin Pool (mbp) wrote :

As explained in https://code.edge.launchpad.net/~lifeless/bzr/bug-416732/+merge/10828 this isn't actually a problem to worry about, just a bug in check causing noise.

Changed in bzr:
status: Fix Committed → Fix Released
Edmundo (eantoranz) wrote :

I'm seeing this problem on bzr 1.18 (updated, on kubuntu jaunty).

I just branched from another repo and I get a Missing Inventory line for every revision the branch has.
Standalone tree (format: pack-0.92)

This is fixed in 2.0

I don't remember the number that its a dupe of, sorry.

 status invalid

Changed in bzr:
status: Fix Released → Invalid
Vincent Ladeuil (vila) on 2010-09-20
Changed in bzr:
status: Invalid → Fix Released
status: Fix Released → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers