Stacked on location breaks if the stacked upon branch is renamed

Reported by Tim Penhey on 2009-05-17
96
This bug affects 15 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Critical
Tim Penhey

Bug Description

The stacked on location is stored in two places:
  - the database
  - the filesystem of the branch

The database refers to the branches through the database id, however the actual filesystem has a string.

We should create a branch job that is created when a branch is renamed if it has any branches stacked on it.

Jonathan Lange (jml) on 2009-06-05
tags: added: branch-stacking
Max Bowsher (maxb) wrote :

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.

Jeroen T. Vermeulen (jtv) wrote :

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

Jeroen T. Vermeulen (jtv) wrote :

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

Andrew Bennetts (spiv) 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.

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

Tim Penhey (thumper) wrote :

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?

Michael Hudson-Doyle (mwhudson) wrote :

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.

Andrew Bennetts (spiv) wrote :

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()

Andrew Bennetts (spiv) wrote :

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.

Tim Penhey (thumper) wrote :

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.

Changed in launchpad:
assignee: nobody → Tim Penhey (thumper)
importance: High → Critical
status: Triaged → In Progress

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?

Launchpad QA Bot (lpqabot) wrote :
Changed in launchpad:
milestone: none → 11.04
tags: added: qa-needstesting
Changed in launchpad:
status: In Progress → Fix Committed
Martin Pool (mbp) wrote :

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

William Grant (wgrant) on 2011-04-07
Changed in launchpad:
milestone: 11.04 → 11.05
Max Bowsher (maxb) wrote :

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

William Grant (wgrant) wrote :

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

tags: added: qa-untestable
removed: qa-needstesting
Tim Penhey (thumper) wrote :

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.

tags: added: qa-ok
removed: qa-untestable
William Grant (wgrant) on 2011-04-11
Changed in launchpad:
status: Fix Committed → In Progress
Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-needstesting
removed: qa-ok
Changed in launchpad:
status: In Progress → Fix Committed
Launchpad QA Bot (lpqabot) wrote :

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

tags: added: qa-untestable
removed: qa-needstesting
Changed in launchpad:
status: Fix Committed → Fix Released
Vincent Ladeuil (vila) wrote :

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

Tim Penhey (thumper) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions