Order of merges and the appearance of the revision history

[Nicholas Allen]

Joseph Wakeling wrote:
> Something that's started to bother me is that revision history in bzr is
> dependent not just on what patches are in the system but also on what
> order merges and pulls happened.
>
> I've attached a simple little shell script to show what I mean.  It
> creates two divergent branches (1 and 2) and then clones each into a and
> b copies.
>
> 1a merges from 2a, and 2a then pulls from 1a.
>
> 2b merges from 1b, and 1b then pulls from 2b.
>
> Now, if we look at either an a branch or a b branch with bzr viz, the
> revision history is topologically identical, but it's displayed
> differently depending on the order of the merge.
>   

When you merge one branch into another, the branch you merged from is 
always the second parent of the committed revision. This is actually 
really nice as it means when you browse the history you can see who 
merged what and into which branch it was merged (rather than just 
knowing 2 branches got merged together).

But bzr can also prevent this if you want. If you use bound branches 
then the revisions will always be in a predictable order and revision 
numbers will not change. So if you have a trunk branch and you always 
use checkouts or bound branches to commit to that shared branch the 
revision numbers will always refer to the same revision on trunk branch. 
Recent versions of bzr can also enforce this behavior for branches where 
this is required.

I was originally skeptical too of bzr's behavior but it really is very 
useful to see in the history that a merge was from one branch to another 
and not just the fact that 2 branches came together without an idea of 
which was merged into which. In the case where multiple developers push 
to a shared location this can also be prevented (so that all commits on 
the trunk appear as merges of a developer's branch into the trunk and 
not the other way round) if this is not desired so bzr really gives you 
the best of both worlds...

It's very hard to explain and I know I didn't do a good job.

Cheers,

Nick