Make --append-revisions-only the default for new branches

[David Strauss]

It was confusing as a new Bazaar user to find that the central branch (which I created by reading and following all obvious direction) had its revision history change every time a developer used "push" to integrate his or her changes into the central branch.

The central branch should never tolerate, by default, any changes to its existing revision history, at least remotely.

Really, I only use remote branches for two use cases:
* A mirror of a local branch, in which case the remote branch will always trivially append changes from my local branch.
* A collaborative branch, in which I want existing history to be immutable by collaborators.

There may be a use case for doing wacky things to the revision history on the remote branch, and I'm fine with supporting that, but it should not be the default.

[John A Meinel (jameinel)]

This is really more of a wishlist/mailing list discussion topic than a specific bug.

There has been a fair amount of discussion in this merge proposal about append_revisions_only handling:
https://code.launchpad.net/~slyguy/bzr/bzr.strict_append_revisions_only/+merge/18267

I don't think there has been any sort of vote on it, to determine who really uses 'bzr pull' to pull in stuff from another branch without merging and 'bzr merge --pull', etc.

Note that mysql devs have also generally refused to set append_revisions_only on their trunk branch, as it was considered too disruptive for the development workflow that they are used to.

[Martin Pool (mbp)]

On 12 February 2010 04:04, John A Meinel <email address hidden> wrote:
> Note that mysql devs have also generally refused to set
> append_revisions_only on their trunk branch, as it was considered too
> disruptive for the development workflow that they are used to.

It seems like it would help them, but they may need other parts first.

At the moment people tend to merge trunk then to try to push to it.

This could be handled by the 'merge --reverse' idea, for which there
is a wishlist bug, letting them construct a new revision in which
their changes are the second parent and the trunk is the first. They
could then push into append_revisions_only.

Alternatively they could commit into a branch bound to trunk, but
perhaps there's some reason they can't do that now.

--
Martin <http://launchpad.net/~mbp/>

[John Szakmeister (jszakmeister)]

My team is using 'bzr pull' all the time. We had the exact situation just happen yesterday, where someone did some work in a branch and pushed it. Unfortunately, we had append_revisions_only misconfigured, so it reorder the revs. Very frustrating. :-( Fortunately, I had an up-to-date copy of trunk and was able to get the ordering we had back. Still, it was very confusing for everyone.

[Martin Pool (mbp)]

lots of history in
https://code.launchpad.net/~slyguy/bzr/bzr.strict_append_revisions_only/+merge/18317
https://code.launchpad.net/~vila/bzr/bzr.strict_append_revisions_only/+merge/23916

They basically ended up just improving the option to be harder to accidentally mis-set.

I think doing this change is technically trivial. The only concern is whether people will find it disruptive.

One option to put it in is to just tell people: use -Oappend_revisions_only=false if you don't like it. We could add a specific option for that.

Eventually it would be good to do a merge --into option.

[Jelmer Vernooij (jelmer)]

Am 01/12/11 07:45, schrieb Martin Pool:
> lots of history in
> https://code.launchpad.net/~slyguy/bzr/bzr.strict_append_revisions_only/+merge/18317
> https://code.launchpad.net/~vila/bzr/bzr.strict_append_revisions_only/+merge/23916
>
> They basically ended up just improving the option to be harder to
> accidentally mis-set.
>
> I think doing this change is technically trivial. The only concern is
> whether people will find it disruptive.
>
> One option to put it in is to just tell people: use
> -Oappend_revisions_only=false if you don't like it. We could add a
> specific option for that.
I think if we wanted to make append_revisions_only the default then I
think we should consider fixing bug 605067 "want option to allow
uncommit but disallow changing mainline" first. Speaking for myself,
uncommit is the main reason that I don't use append-revisions-only on my
local branches, and it would be quite annoying to have to unset it every
time I want to uncommit (I use uncommit a lot).

>
> Eventually it would be good to do a merge --into option.
Yeah, that would indeed be a neat option. Perhaps a separate command,
"bzr land" ?

Cheers,

Jelmer

[Christian Hudon (chrish)]

I've been reading stuff like the following a few times on the bazaar mailing-list:

----

From: Martin Pool <mbp <at> sourcefrog.net>
Subject: Re: Is "bzr push" safe?
Newsgroups: gmane.comp.version-control.bazaar-ng.general
Date: 2011-11-30 00:13:29 GMT (8 weeks, 2 days, 20 hours and 13 minutes ago)

Hi Patrick,

What this is referring to is that pushing a per-task (eg per-bug)
branch over the mainstream branch will cause a change to the mainline
of trunk. No data is lost, but the graph of revisions will be
presented differently and this may be disturbing.

You can set append_revisions_only to avoid this happening and we
probably should make that option the default.

----

(At http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/73395)

I also agree that the current behavior of bazaar where the mainline changes silently if you don't pay attention about the direction you do your merges (or are not aware that said merge direction is important) is confusing. I thought I'd come here and create a bug to prod things along about changing the default, but such a bug already exists. So I'm adding this here instead.