automatic stacking format upgrade doesn't work over the smart server

Bug #388675 reported by Michael Hudson-Doyle
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
High
Andrew Bennetts

Bug Description

This is new in 1.16 I think.

This little script reproduces:

rm -rf ~/tmp/repro
mkdir ~/tmp/repro
python -c 'import bzrlib.bzrdir; bzrlib.bzrdir.BzrDir.create("/home/mwh/tmp/repro/bzrdir")'
bzr init --1.6 ~/tmp/repro/bzrdir/stack-on
echo 'default_stack_on = stack-on' > ~/tmp/repro/bzrdir/.bzr/control.conf
bzr init --pack-0.92 ~/tmp/repro/push
bzr push -d ~/tmp/repro/push bzr+ssh://localhost/home/mwh/tmp/repro/bzrdir/stacked

The output is:

Created a standalone tree (format: 1.6)
Created a standalone tree (format: pack-0.92)
Source repository format does not support stacking, using format:
  Packs 5 (adds stacking support, requires bzr 1.6)
Source branch format does not support stacking, using format:
  Branch format 7
Using default stacking branch stack-on at file:///home/mwh/tmp/repro/bzrdir/
bzr: ERROR: The branch 'bzr+ssh://localhost/home/mwh/tmp/repro/bzrdir/stacked/'(Remote BZR Branch) is not a stackable format. You will need to upgrade the branch to permit branch stacking.
HPSS calls: 11 (0 vfs) SmartSSHClientMedium(connected=False, username=None, host='localhost', port=None)

It seems the client thinks the remote branch has been created in 1.6 format, but the server created it in the default format. Or something. It doesn't break (or stack) if the default_stack_on branch is not stackable.

Related branches

summary: - stacking format upgrade doesn't work over the smart server
+ automatic stacking format upgrade doesn't work over the smart server
Martin Pool (mbp)
Changed in bzr:
importance: Undecided → High
description: updated
Martin Pool (mbp)
Changed in bzr:
assignee: nobody → Andrew Bennetts (spiv)
milestone: none → 1.16
status: New → Confirmed
Revision history for this message
Andrew Bennetts (spiv) wrote :

This seems to be a bug involving the BzrDirFormat.initialize_ex_1.16 HPSS verb. It's probably but not technically a regression vs. 1.15 (which probably had the same bug in its BzrDirFormat.initialize_ex verb), but it does seem serious.

Changed in bzr:
milestone: 1.16 → none
status: Confirmed → In Progress
Revision history for this message
Andrew Bennetts (spiv) wrote :

The fix seems straightforward:

=== modified file 'bzrlib/bzrdir.py'
--- bzrlib/bzrdir.py 2009-06-12 03:44:12 +0000
+++ bzrlib/bzrdir.py 2009-06-18 03:15:02 +0000
@@ -3268,6 +3268,8 @@
         else:
             remote_repo = None
             policy = None
+ if require_stacking:
+ bzrdir._format.require_stacking()
         return remote_repo, bzrdir, require_stacking, policy

     def _open(self, transport):

i.e. the issue is that require_stacking() was only being triggered on the server, so the client wasn't choosing the right branch format.

(And so it turns out that the
"""Source repository format does not support stacking, using format:
  Packs 5 (adds stacking support, requires bzr 1.6)
Source branch format does not support stacking, using format:
  Branch format 7"""
lines in the output in the bug report are actually relayed from the *server's* stdio via SSH. Calling require_stacking() again on the client produces those lines again, but locally.)

I'm working on a proper patch with tests etc.

Revision history for this message
Andrew Bennetts (spiv) wrote :

Oh, I didn't mean to untarget this for 1.16 earlier. My update must have crossed with Martin's...

Changed in bzr:
milestone: none → 1.16
Andrew Bennetts (spiv)
Changed in bzr:
status: In Progress → Fix Committed
Revision history for this message
Martin Pool (mbp) wrote :

The mid-air collision was an occurrence of bug 28459, I think.

Revision history for this message
Andrew Bennetts (spiv) wrote :

Fix landed in bzr.dev and on the 1.16 branch.

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.

Other bug subscribers

Remote bug watches

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