Behind the scene:Backout
Shiyuan
Let <startrev> be the revision we're at when we start the backout.
Backout is basically four steps rolled into one:
hg update -C -r <rev-to-backout>
hg revert --all -r <parent of rev-to-backout>
hg commit
hg update -C -r <startrev>
There's a fifth step that is done automatically if you specify --merge :
hg merge (merges <startrev> with the newly committed rev from 3.)
And there's a sixth, manual step:
hg commit (the result of merging)
When step 3 (commit) aborts, you're left with the first two steps completed and you can either:
hg commit yourself to complete it, and/or
hg update -C to abandon the process
Step 4 assures the parents of the committed merge changeset are in the right order. That is : parent1 = <startrev> andparent2 = <the new backout rev>.
Mads Kiilerich
> Hi,
> I want to understand what happens befind Backout/merge/update. I
> find this example on the website
> (http://mercurial.selenic.com/wiki/Backout?highlight=%28backout%29)
> which explains backout.
Note that this page no longer tells the whole truth. The default
behaviour changed in 1.7 as described in
http://markmail.org/thread/z7vkmj5fqb7gd3ce and
http://www.selenic.com/hg/rev/52971985be14 .
> What's the purpose of step 4? It also works for the example provided
> in the same website without step 4.
That's explained at the end of the text you quoted:
> Step 4 assures the parents of the committed merge changeset are in the
> right order. That is : parent1 = <startrev> andparent2 = <the new
> *backout* rev>.
>
> What happens when mercurial tries to merge two files that are
> descendants of one file?
They are merged, as described by 'hg help merge' and the other help
texts referenced there.
/Mads
_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial