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

[Jonathan Lange]

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/', '')

[Robert Collins (lifeless)]

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

[Michael Hudson-Doyle (mwhudson)]

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

[Jonathan Lange (jml)]

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.

[Jonathan Lange (jml)]

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

[Jonathan Lange (jml)]

... 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.

[Jonathan Lange (jml)]

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

<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

[Jonathan Lange (jml)]

Landed in r4433.