"AssertionError: name already in parent" when running update

I have the same trouble with bzr 1.8.

Traceback (most recent call last):
  File "bzrlib\commands.pyo", line 849, in run_bzr_catch_errors
  File "bzrlib\commands.pyo", line 795, in run_bzr
  File "bzrlib\commands.pyo", line 495, in run_argv_aliases
  File "bzrlib\builtins.pyo", line 715, in run
  File "bzrlib\decorators.pyo", line 192, in write_locked
  File "bzrlib\workingtree.pyo", line 1547, in pull
  File "bzrlib\merge.pyo", line 1507, in merge_inner
  File "bzrlib\merge.pyo", line 484, in do_merge
  File "bzrlib\merge.pyo", line 456, in _do_merge_to
  File "bzrlib\merge.pyo", line 595, in do_merge
  File "bzrlib\merge.pyo", line 626, in _compute_transform
  File "bzrlib\merge.pyo", line 676, in _entries3
  File "bzrlib\decorators.pyo", line 138, in read_locked
  File "bzrlib\tree.pyo", line 202, in iter_entries_by_dir
  File "bzrlib\workingtree_4.pyo", line 430, in _get_inventory
  File "bzrlib\workingtree_4.pyo", line 366, in _generate_inventory
AssertionError: name u'.project.THIS' already in parent

Same problem here with bzr 1.9 with commit/revert.

I was trying to commit after a merge from branch B into A in a shared repository. B was initially branched from A
and no other commits had been made to A since. The file buffer_save.txt is new in the B branch.

bzr: ERROR: exceptions.AssertionError: name u'buffer_save.txt' already in parent

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 893, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 839, in run_bzr
    ret = run(*run_argv)
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 539, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/lib/python2.5/site-packages/bzrlib/builtins.py", line 3358, in run
    self._revert_tree_to_revision(tree, revision, file_list, no_backup)
  File "/usr/lib/python2.5/site-packages/bzrlib/builtins.py", line 3368, in _revert_tree_to_revision
    report_changes=True)
  File "/usr/lib/python2.5/site-packages/bzrlib/mutabletree.py", line 52, in tree_write_locked
    return unbound(self, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/bzrlib/workingtree.py", line 1993, in revert
    report_changes)
  File "/usr/lib/python2.5/site-packages/bzrlib/transform.py", line 2249, in revert
    working_tree, target_tree, tt, filenames, backups, pp)
  File "/usr/lib/python2.5/site-packages/bzrlib/transform.py", line 2273, in _prepare_revert_transform
    merge_modified = working_tree.merge_modified()
  File "/usr/lib/python2.5/site-packages/bzrlib/decorators.py", line 138, in read_locked
    result = unbound(self, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/bzrlib/workingtree.py", line 923, in merge_modified
    if file_id not in self.inventory:
  File "/usr/lib/python2.5/site-packages/bzrlib/workingtree_4.py", line 430, in _get_inventory
    self._generate_inventory()
  File "/usr/lib/python2.5/site-packages/bzrlib/workingtree_4.py", line 366, in _generate_inventory
    % (name_unicode,))
AssertionError: name u'buffer_save.txt' already in parent

bzr 1.9 on python 2.5.2 (linux2)
arguments: ['/usr/bin/bzr', 'revert', '-r', '-1']
encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'en_US.UTF-8'
plugins:
  bzr_difftools /home/alf/.bazaar/plugins/bzr_difftools [unknown]
  bzr_xmloutput /home/alf/.bazaar/plugins/bzr_xmloutput [unknown]
  bzrtools /usr/lib/python2.5/site-packages/bzrlib/plugins/bzrtools [1.9.0]
  gtk /usr/lib/python2.5/site-packages/bzrlib/plugins/gtk [0.96.0dev1]
  launchpad /usr/lib/python2.5/site-packages/bzrlib/plugins/launchpad [unknown]
*** Bazaar has encountered an internal error.
    Please report a bug at https://bugs.launchpad.net/bzr/+filebug
    including this traceback, and a description of what you
    were doing when the error occurred

Same problem, but got into this state differently. Had problems pushing files to central branch due to bug 327558. To work around checked files into central depot directly and pulled (after first deleting files locally first). Had forgotten to bzr revert files locally (that I had previously failed to push up), so they were still status=="added". Files that were pulled down still show status "added". Trying to revert gives below error. Uncommited last change, but did not help. At this point I can't further commit anything locally.

bzr: ERROR: exceptions.AssertionError: name u'StyleX' already in parent

Traceback (most recent call last):
  File "bzrlib\commands.pyo", line 896, in run_bzr_catch_errors
  File "bzrlib\commands.pyo", line 842, in run_bzr
  File "bzrlib\commands.pyo", line 542, in run_argv_aliases
  File "bzrlib\builtins.pyo", line 3625, in run
  File "bzrlib\builtins.pyo", line 3635, in _revert_tree_to_revision
  File "bzrlib\mutabletree.pyo", line 52, in tree_write_locked
  File "bzrlib\workingtree.pyo", line 1999, in revert
  File "bzrlib\transform.pyo", line 2351, in revert
  File "bzrlib\transform.pyo", line 2375, in _prepare_revert_transform
  File "bzrlib\decorators.pyo", line 138, in read_locked
  File "bzrlib\workingtree.pyo", line 929, in merge_modified
  File "bzrlib\workingtree_4.pyo", line 417, in _get_inventory
  File "bzrlib\workingtree_4.pyo", line 353, in _generate_inventory
AssertionError: name u'StyleX' already in parent

bzr 1.12 on python 2.5.2 (win32)
arguments: ['bzr', 'revert', 'SourceAnalysis.Targets']
encoding: 'cp1252', fsenc: 'mbcs', lang: None
plugins:
  bzrtools C:\Program Files\Bazaar\plugins\bzrtools [1.12]
  launchpad C:\Program Files\Bazaar\plugins\launchpad [unknown]
  netrc_credential_store C:\Program Files\Bazaar\plugins\netrc_credential_store [unknown]
  qbzr C:\Users\Foo\AppData\Roaming\bazaar\2.0\plugins\qbzr [0.9.8]
  svn C:\Program Files\Bazaar\plugins\svn [0.5]
*** Bazaar has encountered an internal error.

I fixed my problem by manually removing the entries in dirstate file and updating the num_entries. Good that dirstate is human readable.

This looks like a bug in the updating-dirstate code. Which Robert recently worked quite hard on to make sure that if there was any ambiguity it would raise an error early rather than late.

We can re-open this if it is ever reproduced.