merging of branches with nested trees fails when commiting with error about multiple write groups

After some testing I need to correct this:

The error "Already in a write group" seems to be a general error in 0.90.1 when working with subtrees.
I get it anytime I work with subtrees that are joined by reference... This seems to be a separate bug.

I only upgraded to the new version in the hope that merging will work there. Before I worked with 0.15.0 ubuntu.

The error message I get there is following:
bzr: ERROR: exceptions.AssertionError:

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 650, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 612, in run_bzr
    ret = run(*run_argv)
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 304, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/lib/python2.5/site-packages/bzrlib/builtins.py", line 2118, in run
    reporter=reporter)
  File "/usr/lib/python2.5/site-packages/bzrlib/decorators.py", line 165, in write_locked
    return unbound(self, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/bzrlib/workingtree_4.py", line 244, in commit
    result = WorkingTree3.commit(self, message, revprops, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/bzrlib/decorators.py", line 165, in write_locked
    return unbound(self, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/bzrlib/mutabletree.py", line 160, in commit
    revprops=revprops, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/bzrlib/commit.py", line 319, in commit
    self._populate_new_inv()
  File "/usr/lib/python2.5/site-packages/bzrlib/commit.py", line 656, in _populate_new_inv
    path, self.work_tree)
  File "/usr/lib/python2.5/site-packages/bzrlib/repository.py", line 2089, in record_entry_contents
    self.repository.get_transaction())
  File "/usr/lib/python2.5/site-packages/bzrlib/inventory.py", line 211, in find_previous_heads
    assert candidates[ie.revision] == ie
AssertionError

On (22/09/07 16:13), Martin Wimmer wrote:
> After some testing I need to correct this:
>
> The error "Already in a write group" seems to be a general error in 0.90.1 when working with subtrees.
> I get it anytime I work with subtrees that are joined by reference... This seems to be a separate bug.
>

Write groups are a recently introduced feature, so that is why you are
seeing the issues with the new version. As well as write groups being
new subtrees are still experimental, so they are not well tested and
this slipped through.

It seems the interaction with nested trees was not considered when write
groups were introduced, or at least the code was not made to work in
these cases.

Whenever nested trees are worked on again this issue will be sorted out,
but they are not currently under much active development, so I am sorry
to say that they are probably going to remain broken for the near
future.

Thanks,

James

--
  James Westby -- GPG Key ID: B577FE13 -- http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256

I would be willing to contribute to fixing this bug, but as this is the first time I looked under the hood of bazaar, I'd need some guidance.

The Problem seems to be fairly easy:
- A commit builder is created for the top working tree
- some time later, another commit builder is created for the subtree.
- both call start_write_group on the same repository
- the second time start_write_group is called: raise errors.BzrError('already in a write group')

My Personal solution would be:
- add a variable _write_group_nesting_level to repository and initialize it with 0
- every time start_write_group is called, increment it by 1
- every time commit_write_group is called on the repository decrement it by one
- when it reaches 0 in commit_write_group only then call _commit_write_group
- for abort_write_group just abort, and reset the counter to 0.

What do you think?

regards,
Martin

In general the idea is that write groups don't automatically nest, but
rather the caller is clear about when they're starting and stopping.
If you want to change that, you should probably talk to Robert about
it on the list.

I would probably approach this case by looking whether there's an
appropriate lower-level api for committing a subtree, or maybe
splitting commit to introduce such an api.

Apparently Larstiq has a branch with general nested-tree improvements that might address this.