Stacking loop causes unhelpful "unable to obtain lock" errors during "bzr up"

The root cause of this is bug 377519: lp:~openerp/openobject-server/5.0 says it is stacked on lp:~openerp/openobject-server/trunk, but lp:~openerp/openobject-server/trunk says it is stacked on lp:~openerp/openobject-server/5.0. This is almost certainly due to branch renames done via Launchpad, but due to bug 377519 Launchpad doesn't update the stacked-on locations when renames happen.

The workaround is as described in the comments of that bug. (Edit the .bzr/branch/branch.conf files for those branches via SFTP.)

Bzr itself could be more helpful in detecting this situation (a loop in stacked-on locations) and guiding the user towards fixing it, so I'll leave this bug open for that aspect.

Thanks for the Rapid action Andrew.

There is no doubt why Bzr is one the the best VCS.

Thanks.

Hello Andrew,

I just changed the repository from checkout to normal branch and I got it working for me.

Should this lead to close the bug?

Thanks.

Hi Jay,

No, the bug still exists, but that's a good workaround for it.

This makes me suspect its the %7E vs ~ thing leading to a checkout
thinking it has a different parent and locking its own master twice.

Actually I ran some tests to see how I should fix the branches mentioned in this bug, but I couldn't figure out if something needed to be fixed.

When I create test stacked branches, the parent_location *and* stacked_on_location are both set in the branch.conf on bazaar.launchpad.net. If I empty the branch.conf via sftp, I can indeed make the branch unusable because it cannot locate its revisions.
If I then do a push --overwrite, it apparently re-uploads all revisions, resets the branch to being non-stacked, and make it usable again (but not stacked). Interestingly, this is also one of the only ways I found to be able to create push new non-stacked branches in existing projects.

Now, for our aforementioned branches, only the parent_location is set in branch.conf, and I do not understand how this is related to stacking, as none of the branches seem to be stacked (perhaps they were before).
But both branches have their parent location pointing to each other, indeed.

The database doesn't seem to think there is any stacking either, because the branches' pages at code.launchpad.net do no say they are stacked.

So... as apparently there is no stacking, is it safe for us to remove the parent_location in the branch.conf of these branches? (or at least in one of them?). What is its purpose?

Thanks!

On 5 March 2011 00:19, Olivier Dony (OpenERP) <email address hidden> wrote:
> Actually I ran some tests to see how I should fix the branches mentioned
> in this bug, but I couldn't figure out if something needed to be fixed.
>
> When I create test stacked branches, the parent_location *and* stacked_on_location are both set in the branch.conf on bazaar.launchpad.net. If I empty the branch.conf via sftp, I can indeed make the branch unusable because it cannot locate its revisions.
> If I then do a push --overwrite, it apparently re-uploads all revisions, resets the branch to being non-stacked, and make it usable again (but not stacked). Interestingly, this is also one of the only ways I found to be able to create push new non-stacked branches in existing projects.
>
> Now, for our aforementioned branches, only the parent_location is set in branch.conf, and I do not understand how this is related to stacking, as none of the branches seem to be stacked (perhaps they were before).
> But both branches have their parent location pointing to each other, indeed.
>
> The database doesn't seem to think there is any stacking either, because
> the branches' pages at code.launchpad.net do no say they are stacked.
>
> So... as apparently there is no stacking, is it safe for us to remove
> the parent_location in the branch.conf of these branches? (or at least
> in one of them?). What is its purpose?

The parent_location gives the default source for pull and merge
commands, if no location is given on the command line. It shouldn't
have any affect on stacking. If removing it makes things work then
they previously weren't, that's interesting information for this bug.

Perhaps bug 733350 is related?