Bazaar

bzr uses inaccessible, internal URL when pushing to server with host-relative default_stack_on url

Bug #385132 reported by Jonathan Lange
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
Critical
Jonathan Lange
Bazaar 1.16 "yesterday-in-california"

Bug Description

When I try to push a branch to development Launchpad server running Bazaar 1.15, I get:

$ bzr push lp://dev/~jml/gnome-terminal/new-branch-2
Using default stacking branch /~jml/gnome-terminal/trunk at lp-47059052510160:///~jml/gnome-terminal
Source format does not support stacking, using format: '1.6'
  Packs 5 (adds stacking support, requires bzr 1.6)

bzr: ERROR: Unsupported protocol for url "lp-47059052510160:///~jml/gnome-terminal/trunk"
HPSS calls: 2 (0 vfs) SmartSSHClientMedium(connected=False, username=None, host='bazaar.launchpad.dev', port=None)

You can reproduce this:
  1. [CLIENT] cd some-branch; bzr push bzr+ssh://remote-host/tmp/server/trunk
  2. [SERVER] BzrDir.create('file:///tmp/server')
  3. [SERVER] echo 'default_stack_on=/tmp/server/trunk' > /tmp/server/.bzr/control.conf
  4. [CLIENT] bzr push bzr+ssh://remote-host/tmp/server/new-branch

This behaviour occurs in bzr.dev r4416 and in the bzr/1.15 branch.

http://paste.ubuntu.com/191522/ has the relevant section of the .bzr.log. Probably the most relevant lines are:
2.258 hpss call: 'BzrDirFormat.initialize_ex', 'Bazaar-NG meta directory, format 1\n', '~jml/gnome-terminal/new-branch-2/', 'False', 'False', 'False', '', 'file:///home/jml/src/organic/python/', 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\n', 'True', 'False'
2.258 (to bzr+ssh://bazaar.launchpad.dev/%7Ejml/gnome-terminal/new-branch-2/)
[18692] 2009-06-09 19:11:35.034 INFO: Using default stacking branch /~jml/gnome-terminal/trunk at lp-47059052510160:///~jml/gnome-terminal
2.856 result: ('.', 'no', 'no', 'yes', 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\n', 'Bazaar-NG meta directory, format 1\n', 'Bazaar-NG meta directory, format 1\n', 'True', '/~jml/gnome-terminal/trunk', 'lp-47059052510160:///~jml/gnome-terminal', '')

With the above repro script, these lines become:
3.645 hpss call: 'BzrDirFormat.initialize_ex', 'Bazaar-NG meta directory, format 1\n', 'tmp/server/trunk/', 'False', 'True', 'False', '', 'file:///home/jml/src/organic/python/', 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\n', 'True', 'False'
3.645 (to bzr+ssh://remote-host/tmp/server/trunk/)
3.909 result: ('.', 'no', 'no', 'yes', 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\n', 'Bazaar-NG meta directory, format 1\n', 'Bazaar-NG meta directory, format 1\n', 'False', '', 'file:///home/jml/src/organic/python/', '')

See original description
Tags: hpss
Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 385132] [NEW] bzr uses inaccessible, internal URL when pushing to server with host-relative default_stack_on url

Just quickly this is probably due to an LP plugin doing something
unexpected: this code path is tested with regular servers, and in those
cases a local chroot transport is in use but is correctly translated
back to the external url.

-Rob

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

I can't reproduce this outside a launchpad context. Haven't tried in a launchpad context yet...

Revision history for this message
Jonathan Lange (jml) wrote :

Rob, my tests show that the return value contains an untranslated file:/// URL, even when there's no Launchpad value involved. It's of course possible that the client is smart enough to translate (or ignore) these.

I think we aren't seeing the failure with the repro script above because we're running against a local server, so file:/// URLs resolve on the client side.

description: updated
Revision history for this message
Jonathan Lange (jml) wrote :

I *can* reproduce the bug without Launchpad, as long as the smartserver is not the local machine. I've updated the bug description accordingly.

description: updated
Revision history for this message
Jonathan Lange (jml) wrote :

... and here's a bundle with tests that reproduce the bug. The first test discovers what I believe to be a related bug, the second test exactly reproduces the failure afaict.

Branch at lp:~jml/bzr/default-stacking-bug-385132.

Revision history for this message
Jonathan Lange (jml) wrote :

<lifeless> jml: is it the value for final_stack or final_stack_pwd that are wrong?
<jml> lifeless: wrt bug 385132? Whatever the second-last value in the returned tuple is, that's the one that's wrong.
<lifeless> thats final_stack_pwd
<lifeless> it should be a relpath, I think, for our cases
<lifeless> there are unit tests for this api
<lifeless> in bzrlib.tests.bzrdir_implementations (or perhaps per_bzrdir).test_bzrdir
<jml> lifeless: thanks, that helps.

Jonathan Lange (jml)
Changed in bzr:
assignee: nobody → Jonathan Lange (jml)
status: Triaged → In Progress
Revision history for this message
Jonathan Lange (jml) wrote :

<jml> spiv: thanks. any thoughts on the fact that bzr 1.15 will break on pushing new branches to Launchpad?
<spiv> jml: I don't have any great ideas about what to do for old clients.
<lifeless> jml: are there client side changes needed?
<jml> lifeless: yes.
<lifeless> jml: thats surprising to me.
<lifeless> if 1.15 is broken, 1.15.2
<lifeless> or bump the server verbs if needed.
<spiv> Launchpad (and potentially bzr core) could peek at the 'Software version' header and reply with UnknownMethod for that verb...
<jml> lifeless, spiv: I think this is something that we can resolve over the next week before the final release.
<spiv> jml: +1

Changed in bzr:
status: In Progress → Fix Committed
Revision history for this message
Jonathan Lange (jml) wrote :

Landed in r4433.

Changed in bzr:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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