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

[Martin Wimmer]

I have a branch that has 3 nested trees that have been joined to the main tree by reference

Some time ago I branched it to implement an experimental feature, and now I wanted to merge it back to the trunk.

bzr merge worked like a charm, and also merged the subtrees.

The commit fails with: "bzr: ERROR: already in a write group"
I use Version 0.90.1 - ubuntu

I can commit any of the subtrees, but its impossible to commit the branch itself.

I hope you can fix this soon, as I don't know how to work around this bug.

[Martin Wimmer (martin-wimmer)]

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

[James Westby (james-w)]

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

[Martin Wimmer (martin-wimmer)]

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

[Martin Pool (mbp)]

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.

[Martin Pool (mbp)]

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