Comment 2 for bug 683307

This is because of a branch being configured to be stacked on itself, which shouldn't happen, but we seem to be getting this reported a few times recently.

Specifically, ~sleepynate/tart/tart-sleepynate is stacked on ~andreesie/tart/vanilla, which is stacked on ~andreesie/tart/vanilla.

So really it is ~andreesie/tart/vanilla which is broken, but anything stacked on it will also be broken. You can see this by inspecting the branch.conf files:
http://bazaar.launchpad.net/~sleepynate/tart/tart-sleepynate/.bzr/branch/branch.conf
http://bazaar.launchpad.net/~andreesie/tart/vanilla/.bzr/branch/branch.conf

I'm not really sure how we got this situation, but I wonder about the recent changes to "lp:foo" resolution. lp:foo use to resolve to .../~user/foo/branch, but now it resolves to /+branch/foo.

I'm suspecting that, because I see the parent pointers in both cases are:
parent_location = ../../../%2Bbranch/tart/

For starters, that is usually only set by something like "bzr branch lp:X lp:Y".

However, if lp:tart == lp:~andreesie/tart/vanilla, I don't see how you could branch something into itself.

Perhaps lp:tart got pointed to a new branch at some point? Such as doing:

 bzr branch lp:tart lp:~andreesie/tart/vanilla

And then going to Launchpad and changing the development focus.

However, that wouldn't explain how lp:~andreesie/tart/vanilla would get stacked on itself.

Now, if lp:~andreesie/tart/vanilla was told to stack on top of /+branch/tart, which then got expanded late, that might cause this problem. If we have code that checked "if stacking_location == this_location" that check might fail to notice that +branch/tart is the same as ~andreesie/tart/vanilla.