Pushing after merge considered harmful

[Alexander Belchenko]

Eli Zaretskii пишет:
>> From: Alexander Belchenko <bialix at ukr.net>
>> Date: Tue, 26 Jan 2010 11:20:05 +0200
>>
>> This option works on the individual branch level, not at the repo level.
> 
> But then it needs to be set for every branch in the repo for which we
> want it, right?

Right. But I suppose you really need this for authoritative branches: trunk, and for release branches.

Regular development branches (feature branches) is less affected by mainline revno changes because 
they are supposed to be merged in trunk in the end. That's how I'm use ARO.

>> I will try to explain the option, but I'm not native Englishman.
> 
> I read Russian, if you prefer (though others here might not be
> amused ;-).  But you have nothing to be embarrassed for about your
> English.

Thanks :-) Anyway, I need more practice in English, I know.

>> It prevents push to change revno for existing revisions in the branch.
> 
> See, that's what confuses me about the description in the docs: a
> "revno" is just a number of a revision.  It is not the revision
> itself.  A revision, AFAIU, is a node in the history DAG.  So why are
> you talking about the revno? do you really mean the revision number,
> or do you mean the revision itself?

Revision number is short alias to use instead of revision identifier.
It's value depends on mainline history (left hand history). So if mainline won't change then 
existing numbers won't change too. Most of the time we operate with revision numbers in bzr. So 
having constant revnos for some (main) branches makes big sense. You are use them in the 
conversations with other developers who has the same copy of the branch and you know that you both 
speak about the same thing. It's very handy.

>> Then push won't work (with append option set) because in the result the 
>> mainline history will change: your local commits become mainline, and 
>> diverged mainline become merged (dotted) revisions.
> 
> What if I first merge _into_ url/to/foo?  Suppose I have a branch that
> is a mirror of url/to/foo, let's call it mirror.  That is:
> 
>   bzr branch --bind url/to/foo mirror
>   bzr branch mirror foo
>   cd foo
>   # hack-hack-hack
>   bzr commit -m "my hacks"
>   cd ../mirror
>   bzr up
>   cd ../foo
>   bzr merge
>   bzr commit -m "merge from trunk"
>   # hack-hack-hack
>   bzr commit -m "more hacks"
>   cd ../mirror
>   bzr merge ../foo
>   bzr commit "merged feature foo"
> 
> will this work with the append option set?

Yes, it will work fine. You may omit the merge from mirror to foo branch if you confident there will 
not be very much conflicts. But in general your workflow seems close to ideal.

>> Also `push --overwrite` won't work if branches are diverged.
>>
>> Also this option prevents uncommit for this branch. (Again because it 
>> will change mainline history).
> 
> The latter of these two sounds like a loss in important functionality.

I can't agree about `push --overwrite`: this is implicit destructive operation by their nature. I 
think it's good that ARO will prevent it.

The uncommit is explicit destructive operation. There is very important reason to not allow it for 
any authoritative public branch: somebody may have the mirror of that branch already, so your 
uncommit won't change their history but definitely made their mirrors diverged.

Anyway, ARO is not set in stone, this is option in branch.conf. Thus it can be enabled and disabled 
(maybe not so easy) by user intent. So if you really really really need to perform destructive 
operation over the branch you can temporarily disable ARO, perform your deeds, and re-enable ARO 
after that.