bzr init doesn't set stacking branch from default

[Martin Pool]

mbp@joy% bzr init lp:~/launchpad/remove-bsondump2
Using default stacking branch /+branch-id/24637 at bzr+ssh://bazaar.launchpad.net/~mbp/launchpad/
Created a standalone branch (format: unnamed)
HPSS calls: 28 (11 vfs) SmartSSHClientMedium(bzr+ssh://<email address hidden>/)

but the branch is apparently not actually stacked:

mbp@joy% bzr init lp:~/launchpad/remove-bsondump2
Using default stacking branch /+branch-id/24637 at bzr+ssh://bazaar.launchpad.net/~mbp/launchpad/
Created a standalone branch (format: unnamed)
HPSS calls: 28 (11 vfs) SmartSSHClientMedium(bzr+ssh://<email address hidden>/)

For a large branch, this of course causes horrible performance when you push to it.

[Martin Pool (mbp)]

The trace for creation is as below, and it does look like it's not setting the right stacked-on branch.

Mon 2012-02-20 18:26:03 +1100
0.049 bazaar version: 2.6.0dev1
0.049 bzr arguments: [u'init', u'lp:~/launchpad/remove-bsondump2']
0.051 looking for plugins in /home/mbp/.bazaar/plugins
0.096 looking for plugins in /usr/lib/python2.7/dist-packages/bzrlib/plugins
0.097 Plugin name launchpad already loaded
0.100 encoding stdout as sys.stdout encoding 'UTF-8'
0.131 hpss: Built a new medium: SmartSSHClientMedium
0.131 hpss call: 'mkdir', '/~mbp/launchpad/remove-bsondump2', ''
0.131 (to bzr+ssh://bazaar.launchpad.net/~mbp/launchpad/remove-bsondump2/)
0.151 ssh implementation is OpenSSH
6.499 result: ('ok',)
6.502 hpss call: 'BzrDir.open_2.1', '~mbp/launchpad/remove-bsondump2/'
6.502 (to bzr+ssh://bazaar.launchpad.net/~mbp/launchpad/remove-bsondump2/)
6.971 result: ('no',)
6.972 hpss call: 'mkdir', '/~mbp/launchpad/remove-bsondump2', ''
6.972 (to bzr+ssh://bazaar.launchpad.net/~mbp/launchpad/remove-bsondump2/)
7.300 result: ('FileExists', '/srv/bazaar.launchpad.net/mirrors/00/08/c7/12')
7.301 hpss call: 'BzrDirFormat.initialize', '~mbp/launchpad/remove-bsondump2/'
7.301 (to bzr+ssh://bazaar.launchpad.net/~mbp/launchpad/remove-bsondump2/)
7.651 result: ('ok',)
7.651 hpss call: 'BzrDir.open_2.1', '~mbp/launchpad/remove-bsondump2/'
7.651 (to bzr+ssh://bazaar.launchpad.net/~mbp/launchpad/remove-bsondump2/)
7.982 result: ('yes', 'no')
7.982 hpss call: 'BzrDir.get_config_file', '~mbp/launchpad/remove-bsondump2/'
7.982 (to bzr+ssh://bazaar.launchpad.net/~mbp/launchpad/remove-bsondump2/)
8.311 result: ()
8.312 0 body bytes read
8.312 hpss call: 'BzrDir.find_repositoryV3', '~mbp/launchpad/remove-bsondump2/'
8.312 (to bzr+ssh://bazaar.launchpad.net/~mbp/launchpad/remove-bsondump2/)
9.865 result: ('norepository',)
9.867 hpss call: 'BzrDir.open_2.1', '~mbp/launchpad/'
9.867 (to bzr+ssh://bazaar.launchpad.net/~mbp/launchpad/remove-bsondump2/)
10.408 result: ('yes', 'no')
10.409 hpss call: 'BzrDir.get_config_file', '~mbp/launchpad/'
10.409 (to bzr+ssh://bazaar.launchpad.net/~mbp/launchpad/remove-bsondump2/)
11.039 result: ()
11.040 37 body bytes read
11.040 hpss call: 'BzrDir.find_repositoryV3', '~mbp/launchpad/'
11.040 (to bzr+ssh://bazaar.launchpad.net/~mbp/launchpad/remove-bsondump2/)
11.681 result: ('norepository',)
[15237] 2012-02-20 18:26:15.094 INFO: Using default stacking branch /+branch-id/24637 at bzr+ssh://bazaar.launchpad.net/~mbp/launchpad/
11.683 hpss call: 'BzrDir.create_repository', '~mbp/launchpad/remove-bsondump2/', 'Bazaar repository format 2a (needs bzr 1.16 or later)\n', 'False'
11.684 (to bzr+ssh://bazaar.launchpad.net/~mbp/launchpad/remove-bsondump2/)
12.095 result: ('ok', 'yes', 'no', 'yes', 'Bazaar repository format 2a (needs bzr 1.16 or later)\n')
12.097 hpss call: 'BzrDir.open_2.1', '+branch-id/24637/'
12.097 (to bzr+ssh://bazaar.la...

[Vincent Ladeuil (vila)]

$ bzr config -d lp:~mbp/launchpad/remove-bsondump2
branch:
  stacked_on_location = /+branch-id/24637

So the config seems ok, regression in push ?

Anyway, -Dhpps -Dhpssvfs on push may tell more about what is happening.

And a way to check what /+branch-id/24637 is will be welcome too ;_;

[Vincent Ladeuil (vila)]

Confirmed for 2.0 nothing new but worth fixing at least for 2.5. Given that it seems to be rare enough to have never been reported, I'm not sure it's worth backporting to older releases.