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.