confusing msg about not supporting stacking on 2a branch
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Bazaar |
Confirmed
|
Medium
|
Unassigned | ||
Bug Description
I grabbed the latest bzr 2.0 branch, branch it and merged in changes from a feature branch in an old format. Pushig the new feature branch to LP says ...
Source branch format does not support stacking, using format:
Branch format 7
Using default stacking branch /~bzr-pqm/
Created new stacked branch referring to /~bzr-pqm/
That should happen IIUIC - the source branch is in format 2a and should therefore support stacking. Here's what info -v says ...
Repository tree (format: 2a)
Location:
shared repository: /home/ian/
repository branch: .
Related branches:
push branch: bzr+ssh:
parent branch: /home/ian/
submit branch: http://
Format:
control: Meta directory format 1
working tree: Working tree format 6
branch: Branch format 7
repository: Development repository format - rich roots, group compression and chk inventories
| Changed in bzr: | |
| importance: | Undecided → Medium |
| status: | New → Confirmed |
| tags: | added: check-for-breezy |
There may already be a bug for this, although I'm not sure which one off-hand.
I'm pretty sure these three lines:
"""
Source branch format does not support stacking, using format:
Branch format 7
Using default stacking branch /~bzr-pqm/
"""
are actually coming from stderr on the *server*. The third one definitely is.
Probably a large part of fixing this is to stop random trace.note() calls that happen in a smart server from escaping to stderr. stderr is often not transmitted to the client for a smart server (e.g. for TCP or HTTP smart servers), and for that matter whether the client SSH process displays stderr isn't something we have much control over either.
The other part of this is that "Source branch format does not support stacking" is a bit inaccurate, because the server doesn't have direct access to the source. Perhaps the tangled stacking logic needs a bit more untangling, but if we avoid emitting on stderr in the server then it won't matter.