"maximum recursion depth exceeded while calling a Python object" on self-stacked branch

[James Tait]

I have a local branch and I wanted to compare it against a branch hosted on Launchpad to make sure I could delete the local copy. IIRC the local branch was created yesterday via "bzr branch lp:hedera thunderbird3". At that point lp:hedera should have been pointing to the thunderbird3 series, which was backed by the branch lp:~jamestait/hedera/thunderbird3. I have since moved some things around:

I renamed the trunk series, pointing to lp:~jamestait/hedera/trunk to thunderbird2
I renamed the branch lp:~jamestait/hedera/trunk to thunderbird2
I renamed the thunderbird3 series, pointing to lp:~jamestait/hedera/thunderbird3, to trunk
I renamed the branch lp:~jamestait/hedera/thunderbird3 to trunk

Development focus on the project is trunk, lp:hedera points to lp:~jamestait/hedera/trunk.

Some time in the dim and distant past, there was some problem with branch stacking on this project. Some nice person in #launchpad (IIRC) fixed that, but I don't know how.

Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 912, in exception_to_return_code
    return the_callable(*args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1112, in run_bzr
    ret = run(*run_argv)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 690, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 705, in run
    return self._operation.run_simple(*args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 135, in run_simple
    self.cleanups, self.func, *args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 165, in _do_with_cleanups
    result = func(*args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1127, in ignore_pipe
    result = func(*args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/builtins.py", line 1972, in run
    file_list, revision, old, new, self.add_cleanup, apply_view=True)
  File "/usr/lib/python2.6/dist-packages/bzrlib/diff.py", line 397, in get_trees_and_branches_to_diff_locked
    bzrdir.BzrDir.open_containing_tree_or_branch(old_url)
  File "/usr/lib/python2.6/dist-packages/bzrlib/bzrdir.py", line 1046, in open_containing_tree_or_branch
    tree, branch = bzrdir._get_tree_branch()
  File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 327, in _get_tree_branch
    return None, self.open_branch(name=name)
  File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 349, in open_branch
    setup_stacking=not ignore_fallbacks, name=name)
  File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 2240, in __init__
    self._setup_stacking()
  File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 2251, in _setup_stacking
    self._activate_fallback_location(fallback_url)
  File "/usr/lib/python2.6/dist-packages/bzrlib/branch.py", line 106, in _activate_fallback_location
    repo = self._get_fallback_repository(url)
  File "/usr/lib/python2.6/dist-packages/bzrlib/branch.py", line 226, in _get_fallback_repository
    possible_transports=[self.bzrdir.root_transport])
  File "/usr/lib/python2.6/dist-packages/bzrlib/branch.py", line 168, in open
    return control.open_branch(unsupported=_unsupported)
  File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 349, in open_branch
 [etc...]

bzr 2.2.1 on python 2.6.6 (Linux-2.6.35-23-generic-x86_64-with-Ubuntu-10.10-maverick)
arguments: ['/usr/bin/bzr', 'diff', '--old=lp:hedera']

[Andrew Bennetts (spiv)]

I can reproduce this atm simply by doing "bzr branch lp:hedera".

The problem is that somehow the branch is configured to be stacked on itself. lp:hedera resolves to lp:~jamestait/hedera/trunk, and its branch.conf says "stacked_on_location = /~jamestait/hedera/trunk"

So there's (at least) two bugs:

 1. the infinite recursion when bzr attempts to open this branch. bzr ought to detect the loop and report the problem quickly and helpfully, rather than the lengthy traceback.
 2. that bzr and/or Launchpad allowed the branch to get into this broken state in the first place (assuming no-one hand-edited the branch.conf).

[Andrew Bennetts (spiv)]

Another bug here may be that bzr and/or Launchpad encouraged the elaborate series of branch renames described in the initial report:

"""
I renamed the trunk series, pointing to lp:~jamestait/hedera/trunk to thunderbird2
I renamed the branch lp:~jamestait/hedera/trunk to thunderbird2
I renamed the thunderbird3 series, pointing to lp:~jamestait/hedera/thunderbird3, to trunk
I renamed the branch lp:~jamestait/hedera/thunderbird3 to trunk
"""

If users need to (or feel that they need to) do this then that strongly suggests there's a problem in our user experience somewhere.

[Andrew Bennetts (spiv)]

I think the various aspects of this bug are probably adequately covered by other, more tightly focussed bugs:

> So there's (at least) two bugs:
>
> 1. the infinite recursion when bzr attempts to open this branch. bzr ought to detect the loop and report the problem quickly and helpfully, rather than the lengthy traceback.
> 2. that bzr and/or Launchpad allowed the branch to get into this broken state in the first place (assuming no-one hand-edited the branch.conf).
…
> Another bug here may be that bzr and/or Launchpad encouraged the elaborate series of branch renames described in the initial report:

The first is now covered by bug 726976. The second is covered by bug 377519. The third is probably too nebulous for a good bug report.

Should we just close this report?

[James Tait (jamestait)]

I have no objection to this bug being closed - I have subscribed to the two bugs mentioned as they seem to match what I'm seeing.

As for the third "bug", that can be attributed to newbie mistakes.

[Martin Pool (mbp)]

I'll close this as a dupe.