selective commit sometimes fails with `parent_id not in inventory` error

Bug #140419 reported by Alexander Belchenko
2
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
Low
Robert Collins

Bug Description

I got this error ar least twice. I don't know how to reproduce it on a little tree, but every time this error happened my tree contains newly added dirs, renamed and modified files and simply modified files. When I try to do selective commit (i.e. only one file from all changes) I got error:

G:\work\emulator\port.dev>python E:\Bazaar\mydev\bzr.dev\bzr --no-plugins -Derror ci setup.py
Committing revision 16 to "G:/work/emulator/port.dev/".
modified setup.py
bzr: ERROR: bzrlib.errors.BzrError: parent_id {srccommon-20070917092202-l6ae75sysw93dazj-1} not in inventory

Traceback (most recent call last):
  File "E:\Bazaar\mydev\bzr.dev\bzrlib\commands.py", line 802, in run_bzr_catch_errors
    return run_bzr(argv)
  File "E:\Bazaar\mydev\bzr.dev\bzrlib\commands.py", line 758, in run_bzr
    ret = run(*run_argv)
  File "E:\Bazaar\mydev\bzr.dev\bzrlib\commands.py", line 492, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "E:\Bazaar\mydev\bzr.dev\bzrlib\builtins.py", line 2318, in run
    author=author)
  File "E:\Bazaar\mydev\bzr.dev\bzrlib\decorators.py", line 165, in write_locked
    return unbound(self, *args, **kwargs)
  File "E:\Bazaar\mydev\bzr.dev\bzrlib\workingtree_4.py", line 247, in commit
    result = WorkingTree3.commit(self, message, revprops, *args, **kwargs)
  File "E:\Bazaar\mydev\bzr.dev\bzrlib\decorators.py", line 165, in write_locked
    return unbound(self, *args, **kwargs)
  File "E:\Bazaar\mydev\bzr.dev\bzrlib\mutabletree.py", line 211, in commit
    revprops=revprops, *args, **kwargs)
  File "E:\Bazaar\mydev\bzr.dev\bzrlib\commit.py", line 330, in commit
    self._update_builder_with_changes()
  File "E:\Bazaar\mydev\bzr.dev\bzrlib\commit.py", line 668, in _update_builder_with_changes
    self._populate_from_inventory(specific_files)
  File "E:\Bazaar\mydev\bzr.dev\bzrlib\commit.py", line 740, in _populate_from_inventory
    parent_id, definitely_changed, existing_ie, report_changes)
  File "E:\Bazaar\mydev\bzr.dev\bzrlib\commit.py", line 792, in _record_entry
    path, self.work_tree)
  File "E:\Bazaar\mydev\bzr.dev\bzrlib\repository.py", line 2234, in record_entry_contents
    self.new_inventory.add(ie)
  File "E:\Bazaar\mydev\bzr.dev\bzrlib\inventory.py", line 1180, in add
    raise BzrError("parent_id {%s} not in inventory" %
BzrError: parent_id {srccommon-20070917092202-l6ae75sysw93dazj-1} not in inventory

bzr 0.92.0dev0 on python 2.4.4.final.0 (win32)
arguments: ['E:\\Bazaar\\mydev\\bzr.dev\\bzr', '--no-plugins', '-Derror', 'ci', 'setup.py']

The same in 0.91rc2 and 0.90, but 0.18 works OK.
I think it's *regression*.

Revision history for this message
Alexander Belchenko (bialix) wrote :

OK, I found sequence of commands to reproduce this bug. It's seems that this bug introduced by Ian by his functions _update_builder_with_changes and friends, that build new inventory for commit from scratch.

bzr init
bzr mkdir dir
echo foo > dir/a
echo hello > test
bzr add
bzr ci -m 1

bzr mv dir/a a
echo foo > test

bzr ci test

Committing revision 2 to "E:/temp/1/a/".
bzr: ERROR: parent_id {dir-20070917123406-s42m3ymzg3wafkme-1} not in inventory

This reminds me bugs in 0.15/0.16 that depends on alphabetical sorting of entries in inventory. Because I renamed file 'a' and now this file appears before it's old parent 'dir'. From this point error message makes sense: parent_id indeed not in inventory yet, because it's not processed yet.

Revision history for this message
Ian Clatworthy (ian-clatworthy) wrote :

Thanks for the script to reproduce this. Aaron introduced a fix in 2591 (0.18 was 2600) for a bug along these lines. That fix and associated tests was accidentally backed out by a merge from John (2614). That particular merge was not so hot in that it also backed out a change of Robert's. Robert has since fixed that. I'll reapply Aaron's fix to bzr.dev and 0.92 if poolie wants it.

Having said all that, when I run your script under 0.18 it still falls over so Aaron's patch isn't enough by the look of things.

Revision history for this message
Alexander Belchenko (bialix) wrote : Re: [Bug 140419] Re: selective commit sometimes fails with `parent_id not in inventory` error

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Clatworthy пишет:
> Thanks for the script to reproduce this. Aaron introduced a fix in 2591
> (0.18 was 2600) for a bug along these lines. That fix and associated
> tests was accidentally backed out by a merge from John (2614). That
> particular merge was not so hot in that it also backed out a change of
> Robert's. Robert has since fixed that. I'll reapply Aaron's fix to
> bzr.dev and 0.92 if poolie wants it.
>
> Having said all that, when I run your script under 0.18 it still falls
> over so Aaron's patch isn't enough by the look of things.

Hm. This patch from Aaron solve my problem in my real project, but
fails with my testing sequence of commands. Weird.
It seems there is still some edge cases when entry changing parent.

Ian, I try to debug commit code in bzr.dev -- that's how I found my
sequence of commands. I have one thought: you start to create inventory
for commit from scratch. Why not using pristine inventory from last
committed revision as base? IMO, it may simplify process of gathering
partial changes in the tree for commit.

[µ]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG74RjzYr338mxwCURAmP/AJwKv4KuQCTYaGDJO1GDIAGEBqqdKwCgh0dP
EzRhxd8yGvG+WdavqLARgZA=
=/RXu
-----END PGP SIGNATURE-----

Revision history for this message
Alexander Belchenko (bialix) wrote :

Robert fixed this bug in his performance patch.

Changed in bzr:
assignee: nobody → lifeless
importance: Undecided → Low
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.