Stacked on location breaks if the stacked upon branch is renamed

For the record, if a branch gets into this state, anyone with write access can fix it as follows:

1. Using sftp, get the .bzr/branch/branch.conf, amend it, and put it.

2. Using bzrlib in a python interpreter, open the branch, write-lock it, unlock it. This triggers LP to sync the changed branch.conf to the http/mirrored side of its dual branch storage.

Here's a branch that has gotten into the problem state: https://code.edge.launchpad.net/~dmitrij.ledkov/xiphos/translations

The problem branch was apparently broken by an ownership change for the stacked-on branch.

An alternative fix would be for Launchpad's code hosting server to store the immutable database ID rather than the mutable string in the branch.conf file. This would require intercepting reads and writes to that file to transparently rewrite that setting (similar to how paths are translated on the fly when resolving paths to files/dirs on disk), and of course migrating the existing files.
This would have the advantage of working instantaneously, and it would not require changing a potentially large number of stacked branches in reaction to a single branch renaming.

On Mon, 02 Nov 2009 18:53:02 Andrew Bennetts wrote:
> An alternative fix would be for Launchpad's code hosting server to store
> the immutable database ID rather than the mutable string in the
> branch.conf file. This would require intercepting reads and writes to
> that file to transparently rewrite that setting (similar to how paths are
> translated on the fly when resolving paths to files/dirs on disk), and of
> course migrating the existing files. This would have the advantage of
> working instantaneously, and it would not require changing a potentially
> large number of stacked branches in reaction to a single branch renaming.

Andrew, any help you could offer with regard to this solution would be awesome.
AFAIK the reason that we didn't do this is that we didn't know how to do it.

On Mon, Nov 2, 2009 at 8:45 PM, Tim Penhey <email address hidden> wrote:
> On Mon, 02 Nov 2009 18:53:02 Andrew Bennetts wrote:
>> An alternative fix would be for Launchpad's code hosting server to store
>>  the immutable database ID rather than the mutable string in the
>>  branch.conf file.  This would require intercepting reads and writes to
>>  that file to transparently rewrite that setting (similar to how paths are
>>  translated on the fly when resolving paths to files/dirs on disk), and of
>>  course migrating the existing files. This would have the advantage of
>>  working instantaneously, and it would not require changing a potentially
>>  large number of stacked branches in reaction to a single branch renaming.
>
> Andrew, any help you could offer with regard to this solution would be awesome.
> AFAIK the reason that we didn't do this is that we didn't know how to do it.
>

Actually we talked about it and decided that it would be really
frikkin hard. Times change though.

jml

Jonathan Lange wrote:
> On Mon, Nov 2, 2009 at 8:45 PM, Tim Penhey <email address hidden> wrote:
>> On Mon, 02 Nov 2009 18:53:02 Andrew Bennetts wrote:
>>> An alternative fix would be for Launchpad's code hosting server to store
>>> the immutable database ID rather than the mutable string in the
>>> branch.conf file. This would require intercepting reads and writes to
>>> that file to transparently rewrite that setting (similar to how paths are
>>> translated on the fly when resolving paths to files/dirs on disk), and of
>>> course migrating the existing files. This would have the advantage of
>>> working instantaneously, and it would not require changing a potentially
>>> large number of stacked branches in reaction to a single branch renaming.
>> Andrew, any help you could offer with regard to this solution would be awesome.
>> AFAIK the reason that we didn't do this is that we didn't know how to do it.
>>
>
> Actually we talked about it and decided that it would be really
> frikkin hard. Times change though.

It wouldn't be *that* hard I think. Work, yes, but nothing impossible.
 Would be lots easier if we didn't have to worry about vfs-level branch
access I guess :-)

Cheers,
mwh

On Wed, 04 Nov 2009 09:11:52 Michael Hudson wrote:
> It wouldn't be *that* hard I think. Work, yes, but nothing impossible.
> Would be lots easier if we didn't have to worry about vfs-level branch
> access I guess :-)

Surely some of had to do with how we were exposing the value over http to
other processes like loggerhead and internal services.

Would we have a special rewrite rule that caught the stacked on file and
converted from a number to a path?

Ah yes, internal access over HTTP would have to become a bunch more complicated. We could do it, I guess, but it would be another moving part to fall over.

By the way, here's a Python script to help do part 2 of the workaround in comment #1:

# Usage: touch-branch.py URL

from bzrlib.plugin import load_plugins
load_plugins()

from bzrlib.bzrdir import BzrDir
import sys
b = BzrDir.open(sys.argv[1]).open_branch(ignore_fallbacks=True)
b.lock_write()
b.unlock()

This bug is a regular problem... every week or so a project seems to run afoul of this (not a metric). Most recent example I've seen is bug 726976.

If this isn't going to be fixed soon can we at least apply a band-aid of preventing the rename of any stacked-on branch? That would at least stop users breaking their projects' branches with this bug.

Bumping to critical as it is a relatively common user change and it breaks their experience. A client-side explosion is just as important, or perhaps more so than a server side one.

It happened to me again this week.

This time I renamed the branch, but it was still the development focus so it was quite strange because looking at the other branches page in launchpad the address after the "Stacked on" field looked correct (same address as in the past), but it wasn't.

To fix the problem I run 'bzr reconfigure' on some branches. The problem seems to be fixed (no problem branching/pulling), but in the other branches launchpad web page 'Invalid stacked on' location messages are displayed. I tried different values protocols in the url (lp, bzr+ssh, http), but to no avail. Is there any uri scheme that works?

Fixed in stable r12758 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12758>.

For people who might be experiencing this problem, please be aware we
are working on this, but the fix will be rolled out and tested
gradually. So right at the moment, you won't immediately see existing
branches fixed, and you won't necessarily see this problem avoided on
new renames. That should follow reasonably soon.

Martin

On 06/04/11 17:18, Javier Collado wrote:
> To fix the problem I run 'bzr reconfigure' on some branches. The problem
> seems to be fixed (no problem branching/pulling), but in the other
> branches launchpad web page 'Invalid stacked on' location messages are
> displayed. I tried different values protocols in the url (lp, bzr+ssh,
> http), but to no avail. Is there any uri scheme that works?

Hi Javier,

In the short term, you can make the "Invalid stacked on location"
messages go away by being sure to stack on an URL of the form
bzr+ssh://bazaar.launchpad.net/~user/project/branchname

QA not done yet, but codehosting isn't in nodowntime so this is fine for now.

I've tested the /+branch-id/$(id)s stacking location, for bzr+ssh but the http access for qastaging is a bit broken so I couldn't test that. Sucessfully changed the branch stacked on location, rescanned, and branched to a clean area.

Fixed in stable r12874 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12874>.

Fixed in stable r12881 (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12881) by a commit, but not testable.

Sorry to come late here but how can I (as a regular user) translate a /+branch-id/xxx back to the corresponding path ?

On Fri, 06 May 2011 05:01:53 you wrote:
> Sorry to come late here but how can I (as a regular user) translate a
> /+branch-id/xxx back to the corresponding path ?

You can't.

Perhaps since we have this new stacked on location, we should have a
top level redirect in LP for this, like the +branch/foo one, but using the
id.