normalizing history causes cherry picking workflow problems

[Stuart Bishop]

It seems that now revision numbers can change during certain operations. This causes some problems with cherry picking, for example selecting certain patches from a development branch and merging them into a production branch.

The first issue is that commit messages on the cherry picks will end up pointing to incorrect or even non-existant revision numbers.

The second issue is that there is a race condition, where the revision number of the change to be cherry picked might change between the request being made and the branch owner doing the merge. Or even between hitting 'enter' on the merge request and the merge starting if concurrent updates might be happening on the source branch.

[Martin Pool (mbp)]

The current 0.8pre will rewrite the revision history to canonical form on push and pull.

The main line is set to the left-most parent path. This means that each revision will have one specific revision number anywhere it occurs on the mainline, which is good for consistency.

(A similar failure can happen when uncommitting, but that is presumably less common and people should be aware of the risks.)

The bug describes an unavoidable drawback of allowing revision numbers to ever be rewritten.

[Martin Pool (mbp)]

Needs discussion of pros and cons.

[John A Meinel (jameinel)]

The pre 0.8, you could pull a revision onto other branch, which would give it a new revision number.
post 0.8, we now have the revno as the distance along the left-hand parents, so they are now fixed, regardless of what branch you are currently in.

There is a small period of transition, when the old method is subsumed by the new method. But with the new method, revno is actually completely stable, independent of what branch you are currently in.