maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

I noticed a difference between Bitkeeper and Bzr merges.

In Bitkeeper, merge parents are essentially unordered. The two parents of a
merge are completely equal, and there is no way from the Bitkeeper to history
to say whether one parent was merged into the other or vise versa. The actual
order in which merge parents are listed is based on some deterministic
algorithm (most recent commit date if I recall correctly).

In particular, this means that in Bitkeeper, the result of a pull of A into B
is exactly identical to a pull of B into A. This makes it impossible to
establish the history of pushes into main trees from just the Bitkeeper
history.

In Bzr, merge parents _are_ ordered. Merging B into A gives a different result
from merging A into B. When merging B into A (cd A; bzr merge B), A is the
primary or left-hand parent. The resulting tree has one extra top-level merge
revision following the tip of A, with all merged revisions of B appearing as
sub-revisions of this.

This means that if one merges A into B giving C1, and later merges B into A
giving C2, then C1 and C2 are considered diverged and need another merge
changeset to be consolidated (in Bitkeeper C1 and C2 are identical and need no
further merge).

What this means is that in bzr is _is_ actually possible to see the history of
what was merged into what, at least in some sense.

Unfortunately, it tends to be backwards with usual MySQL working style. This
is to make a branch at some point X, make a patch, commit and get review. Then
when pushing, the main tree has gotten additional pushes by others and is now
at revision Y > X. So one does a bzr merge of the main tree into the local
clone, followed by a push to the main tree. Now the local patch becomes the
main merge parent, and all other pushes between X and Y become sub-revisions
with their revision numbers renamed. Which eventually makes primary/secondary
merge parent relationships more or less random.

So since I did not take part in the transition to bzr within Sun, I just
wanted to ask if this is something that was discussed, and if so if there were
any conclusions?

As I understand, the Drizzle people make sure that whenever they merge, they
merge into a copy of their trunk, so that all past pushes are visible as the
line of primary/left-most merge parents in the main tree. This works better
for them, as they follow the model of a single/few merge captains merging in
other peoples trees upon merge requests.

My personal opinion is that while it would be nice to have the push history
available like the Drizzle people do, the bzr support for this is not good
enough, without a very tight control on who can push to main trees that we do
not want. What one can do is when pushing, first swith to an up-to-date fresh
clone of the main tree, pull from the local branch with own changes, then push
that to the main tree. Maybe this is a good way, even though it cannot be
enforced?

Just wanted to hear if there are any other opinions on this?

 - Kristian.