branching v6 branch into shared repo creates v6 branch

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.

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

On Mon, 2006-04-03 at 20:25 -0400, James Blackwell wrote:

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

This is not the case though. Once you have a shared repo format, you no
longer need to upgrade for this to automatically use the shared repo.
Its presumed you will have an appropriately formatted shared repo you
are pushing the branch to, and thus there is no problem.

This issue will only exist when the bzrdir format bumps, and that should
be extremely rare from here on out: we can add new tree formats, branch
formats etc to the one bzrdir 'metadir' format.

Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

All this discussion about format compatibility is interesting, but I think it misses the point.

Here is the common use case as I see it:
 * Getting branch from http.
 * Do some work.
 * Push branch to [s]ftp.

Automatic upgrade from v6 when getting into a repository indeed breaks roundtripping in that case. However that requires an explicit user action: setting up and using the local repository.

Which one is the easier to explain (assuming a number of new features) how to use repositories:

 * To take advantage shared storage in a repository, just branch into the repository. Unless the source branch is v6 format, then you have use "branch --upgrade". If you want to publish a branch readable by bzr-0.7, use "push --format=v6" when initially pushing the branch.

 * To take advantage of shared storage in a repository, just branch into the repository. If you want to publish a branch readable by bzr-0.7, use "push --format=v6" when initially pushing the branch.

I agree with jblack, upgrade to metadir should be automatic when branching into a repository.

In addition, push (branch, clone?) should have a format option.

It is just annoyingly complicated to explain how to use repositories, when it should be simpler. Especially since v6 branches will stay around for a while. They are fast enough for small branches that it's not worth the trouble of upgrading to knits.

I think now that we are in the second release since shared repositories came out, it would be wise to switch so that 'bzr branch' into a shared repository respects the repository settings, rather than the source.

Otherwise there is always the 'bzr init; bzr pull' workaround.

I would like to see this happen for 0.9, but we need to discuss it again first.

On Fri, 2006-07-21 at 22:47 +0000, John A Meinel wrote:
> I think now that we are in the second release since shared repositories
> came out, it would be wise to switch so that 'bzr branch' into a shared
> repository respects the repository settings, rather than the source.
>
> Otherwise there is always the 'bzr init; bzr pull' workaround.
>
> I would like to see this happen for 0.9, but we need to discuss it again
> first.

I think bzr branch should *always* respect the format of the source.

Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Fri, 2006-07-21 at 22:47 +0000, John A Meinel wrote:
>> I think now that we are in the second release since shared repositories
>> came out, it would be wise to switch so that 'bzr branch' into a shared
>> repository respects the repository settings, rather than the source.
>>
>> Otherwise there is always the 'bzr init; bzr pull' workaround.
>>
>> I would like to see this happen for 0.9, but we need to discuss it again
>> first.
>
> I think bzr branch should *always* respect the format of the source.

I think "always" is too strong a word; at minimum, users should be able
to supply --format to override the format.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEwdfY0F+nu1YWqI0RAhkVAJ9xeoytmNwZ9ysmgADhR1cLw8dRoACfaN2A
0JXo5dzorKm+TvMMCYlHThQ=
=yirs
-----END PGP SIGNATURE-----

On Sat, 2006-07-22 at 07:46 +0000, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Robert Collins wrote:
> > On Fri, 2006-07-21 at 22:47 +0000, John A Meinel wrote:
> >> I think now that we are in the second release since shared repositories
> >> came out, it would be wise to switch so that 'bzr branch' into a shared
> >> repository respects the repository settings, rather than the source.
> >>
> >> Otherwise there is always the 'bzr init; bzr pull' workaround.
> >>
> >> I would like to see this happen for 0.9, but we need to discuss it again
> >> first.
> >
> > I think bzr branch should *always* respect the format of the source.
>
> I think "always" is too strong a word; at minimum, users should be able
> to supply --format to override the format.

I'll happily agree to that.

What I'm thinking of is git, svn, hg plugins - branch from them should
IMO preserve the format, because the branching would become a *lot*
slower in that one case.

So I think having a '--format=automatic' or something, to say 'convert
to the best local representation' would be good, and --format=knit etc
to force a specific format, with the default being to preserve the
format.

Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Actually, with the git, svn and hg plugins, I would want to make a Bazaar branch, because most operations are so much faster with native-format repos.

Aaron