A quick search on the list for "shared" over here didn't show the thread
that you refer to so I'm going to CC this to the list. Since the argument
isn't easy to find I'll unpack a fresh version here.

On Mon, Apr 03, 2006 at 11:13:54PM -0000, Robert Collins wrote:
> This is by design. There is a mailing list thread about this I believe
> where we are considering a --upgrade or similar option. Changing this
> behaviour would break roundtripping of formats which is hostile to users
> with any version skew.

I can see the problem that you're worried about if it were the default:

    Person A makes 0.7 branch.
    Person B with 0.8pre branches into shared repo 
    Person B makes a few commits and pushes
    Person A has to upgrade in order to use person B's branch.

That's a strong argument most of the time. I'm not so sure in this case
after three weeks of experimentation.

One of the benefits of 'shared storage' is that one can generally evade
the download of revisions one already has. Though this doesn't work for
weave->knit, it sould work for weave->metadir which is also a weave
format.

Holding the line in this particular spot eliminates the benefit in this
case because one has to do the following whenever a branch in a different
format is seen. This is painful to those using shared repositories:

  * Download the whole branch
  * Upgrade the branch
  * Introduce branch into shared repo
  * Change the source

The immediate reaction is to automatically upgrade branches so that
conversion is very easy. This immediate reaction is wrong because then it 
removes the ability to not upgrade a branch (which Person B may want in
order to interroperate with Person A). 

So there's a need for an option to declare whether interroperability is
important. A boolean option such as the proposed --upgrade requires a
decision though as to what the default should be. 

The decision with standalone branches is obvious. The whole dataset needs
to be downloaded regardless of the format. Performing a format upgrade
afterwards is generally not very painful as all the downloading has
already happened, though weave->knit is a little bit of an exception. So
with standalone branches, default to not upgrade.

Branches in a shared repo is a different story. A branch in a shared repo
is supposed to rely upon the shared repo to share the revisions with other
related brnaches in the repo. This includes avoiding having to download
revisions that one already has. Which case is more common for users for
shared repos? Ignoring the shared repo and preserving the original format
or ignoring the original format and taking advantage of the shared repo?

I believe its the latter. Branching from others is expensive enough that
I'd always upgrade stuff going into a shared rep and let the other guy pay
the cost of having an old bazaar-ng client. In other words, I'd always use
--upgrade for a branch in a shared repo, because I want the branch to use
shared storage. I bet that would be the common behaviour.

Thusly I probably wouldn't care about preservation with standalone
branches but would care very much about shared repos. Thusly, I suggest
the following:

    bzr branch [--(no-)upgrade] 

 Branch Type        Default
 ----------         ----------
 Standalone         --no-upgrade
 Shared             --upgrade

Yes, this does mean that waterfall effects are not necessary. But I don't
think we evade that by shoving it off into a --upgrade option, as users
would just tuck it into a command alias. If they're going to do it
anyways, then you may as well make it the default for them.*



 * Either that or be ready to continually answer the question each format
   bump about why branches aren't entering the shared repo. This is a sign
   that a opportunity to be intuitive has been missed.



> ** Changed in: bzr (upstream)
>      Priority: None => Wontfix
>        Status: Unconfirmed => Confirmed

-- 
My home page:   <a href="http://jblack.linuxguru.net">James Blackwell</a>
Gnupg 06357400  F-print AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400