using +branch/~user/project/branch prevents automatic stacking of new branches pushed to Launchpad

Bug #741375 reported by Andrew Bennetts
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
Critical
John A Meinel
Launchpad itself
Fix Released
Low
Unassigned

Bug Description

As of r5736 pushes to Launchpad no longer stack on the development focus by default. The difference at the HPSS level appears to be:

Previously:

9.166 hpss call: 'BzrDirFormat.initialize_ex_1.16', 'Bazaar-NG meta directory, format 1\n', '~spiv/bzr/add-doc-for-shared-ssh-server/', 'False', 'False', 'False', '', 'file:/
//home/andrew/warthogs/bzr/add-doc-for-shared-ssh-server/', 'Bazaar repository format 2a (needs bzr 1.16 or later)\n', 'True', 'True'
9.166 (to bzr+ssh://bazaar.launchpad.net/~spiv/bzr/add-doc-for-shared-ssh-server/)
11.236 result: ('.', 'yes', 'no', 'yes', 'Bazaar repository format 2a (needs bzr 1.16 or later)\n', 'Bazaar-NG meta directory, format 1\n', 'Bazaar-NG meta directory, form
at 1\n', 'True', '/~bzr-pqm/bzr/bzr.dev', '.', '')

Now:

6.664 hpss call: 'BzrDirFormat.initialize_ex_1.16', 'Bazaar-NG meta directory, format 1\n', '+branch/~spiv/bzr/add-doc-for-shared-ssh-server/', 'False', 'False', 'False', '',
 'file:///home/andrew/warthogs/bzr/add-doc-for-shared-ssh-server/', 'Bazaar repository format 2a (needs bzr 1.16 or later)\n', 'True', 'True'
6.664 (to bzr+ssh://bazaar.launchpad.net/%2Bbranch/~spiv/bzr/add-doc-for-shared-ssh-server/)
11.486 result: ('.', 'yes', 'no', 'yes', 'Bazaar repository format 2a (needs bzr 1.16 or later)\n', 'Bazaar-NG meta directory, format 1\n', 'Bazaar-NG meta directory, form
at 1\n', 'False', '', 'file:///home/andrew/warthogs/bzr/add-doc-for-shared-ssh-server/', '')

So the different path sent by the client stops the server from replying that it should stack on /~bzr-pqm/bzr/bzr.dev.

It's possible that this is partly a Launchpad bug, but I'm filing on just bzr initially.

Related branches

Andrew Bennetts (spiv)
tags: added: lpurl
Changed in launchpad:
status: New → Triaged
importance: Undecided → Critical
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

LP needs to serve the fake bzrdir that's served at /~user/product/.bzr at /+branch/~user/product/.bzr as well. This sounds simple, but translatePath in lp.code.xmlrpc.codehosting is a bit of a mess of competing abstractions...

Andrew Bennetts (spiv)
Changed in bzr:
assignee: nobody → canonical-bazaar (canonical-bazaar)
Revision history for this message
John A Meinel (jameinel) wrote :

We can easily do it in a different way. If we are supplied a 3-part lp: name, don't use the +branch abstraction.

It is a bit of a pain, and really it has been a latent bug in the Launchpad codehosting for some time.

Specifically, we've never encountered this because you always had to *create* a branch using the 3-part name, and *then* you could turn it into a project series, etc, to be able to access it with a 2-part name. So while we wouldn't stack them with 2-part (lp:bzr/2.2) (or 1-part names like lp:bzr), it didn't matter, because they had to be created with a 3-part name which would stack them.

John A Meinel (jameinel)
Changed in bzr:
assignee: canonical-bazaar (canonical-bazaar) → John A Meinel (jameinel)
summary: - r5736 to resolve lp:foo URLs locally prevents automatic stacking of new
+ using +branch/~user/project/branch prevents automatic stacking of new
branches pushed to Launchpad
John A Meinel (jameinel)
Changed in bzr:
status: Confirmed → In Progress
Revision history for this message
Max Bowsher (maxb) wrote :

> If we are supplied a 3-part lp: name, don't use the +branch abstraction.

Don't forget distro package branches, which have two and three part aliases, and five-part full names.

John A Meinel (jameinel)
Changed in bzr:
milestone: none → 2.4b2
status: In Progress → Fix Committed
status: Fix Committed → Fix Released
Revision history for this message
Aaron Bentley (abentley) wrote :

AFAICT, this was a regression in bzr, not Launchpad, so we can downgrade it to High.

Changed in launchpad:
importance: Critical → High
Revision history for this message
Robert Collins (lifeless) wrote :

Indeed, going further it only affects unreleased bzrs, so there is nothing for us to do.

Changed in launchpad:
status: Triaged → Invalid
Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 741375] Re: using +branch/~user/project/branch prevents automatic stacking of new branches pushed to Launchpad

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/18/2011 12:29 AM, Robert Collins wrote:
> Indeed, going further it only affects unreleased bzrs, so there is
> nothing for us to do.
>
> ** Changed in: launchpad
> Status: Triaged => Invalid
>

This isn't invalid, the core issue is still true.

Specifically, if you do:

 bzr push bzr+ssh://bazaar.launchpad.net/+branch/~user/project/branch

Launchpad will be perfectly happy to accept that request. But will
create a branch that is not stacked. That is a bug. (IMO)

 status: Triaged

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3TgQIACgkQJdeBCYSNAAMuqgCfc//WI+Fj5vMGreT2yIkU93bR
P9wAnRUwHD5+ihCijd03UCNL7P0VK7Kj
=meTI
-----END PGP SIGNATURE-----

Changed in bzr:
status: Fix Released → Triaged
Revision history for this message
Robert Collins (lifeless) wrote :

So if a user manually uses +branch it won't stack. Will that ever
happen automatically?

Revision history for this message
John A Meinel (jameinel) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/18/2011 10:55 AM, Robert Collins wrote:
> So if a user manually uses +branch it won't stack. Will that ever
> happen automatically?
>

If someone else makes the same mistake I did and tries just always
translating the lp:* into /+branch/*. Which almost works but obviously
fails in this way.

bzr itself worked around what I consider a bug in Launchpad by
explicitly detecting this case. (Which gets a bit trickier with distro
branches because then you have a different number of sections, etc.)

So I still think this is a bug in Launchpad codehosting. People won't be
hitting it frequently, so I don't think it is a Critical bug. It may be
just a Low bug, but I think it is still a bug.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3TkAYACgkQJdeBCYSNAAN5TQCfct3xLwI7RYoAAAny9fERp02L
zvYAn0Wz/gS0STyFJJ/SZ2DuEGRxewFT
=/PhL
-----END PGP SIGNATURE-----

Revision history for this message
Vincent Ladeuil (vila) wrote :

@jam: I think you wanted to turn the status to Triaged on the lp bugtask not the bzr one but imbw

Changed in bzr:
milestone: 2.4b2 → none
status: Triaged → Fix Released
milestone: none → 2.4b2
John A Meinel (jameinel)
Changed in launchpad:
status: Invalid → Triaged
Changed in launchpad:
importance: High → Low
Curtis Hovey (sinzui)
Changed in launchpad:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.