Mercurial > hg
view tests/test-copies.t @ 46582:b0a3ca02d17a
copies-rust: implement PartialEqual manually
Now that we know that each (dest, rev) pair has at most a unique CopySource, we
can simplify comparison a lot.
This "simple" step buy a good share of the previous slowdown back in some case:
Repo Case Source-Rev Dest-Rev # of revisions old time new time Difference Factor time per rev
---------------------------------------------------------------------------------------------------------------------------------------------------------------
mozilla-try x00000_revs_x00000_added_x000_copies 9b2a99adc05e 8e29777b48e6 : 382065 revs, 43.304637 s, 34.443661 s, -8.860976 s, × 0.7954, 90 µs/rev
Full benchmark:
Repo Case Source-Rev Dest-Rev # of revisions old time new time Difference Factor time per rev
---------------------------------------------------------------------------------------------------------------------------------------------------------------
mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 1 revs, 0.000043 s, 0.000043 s, +0.000000 s, × 1.0000, 43 µs/rev
mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 6 revs, 0.000114 s, 0.000117 s, +0.000003 s, × 1.0263, 19 µs/rev
mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 1032 revs, 0.004937 s, 0.004892 s, -0.000045 s, × 0.9909, 4 µs/rev
pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 9 revs, 0.000339 s, 0.000196 s, -0.000143 s, × 0.5782, 21 µs/rev
pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 1 revs, 0.000049 s, 0.000050 s, +0.000001 s, × 1.0204, 50 µs/rev
pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 7 revs, 0.000202 s, 0.000117 s, -0.000085 s, × 0.5792, 16 µs/rev
pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 1 revs, 0.000409 s, 0.6f1f4a s, -0.000087 s, × 0.7873, 322 µs/rev
pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 6 revs, 0.011984 s, 0.011949 s, -0.000035 s, × 0.9971, 1991 µs/rev
pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 4785 revs, 0.050820 s, 0.050802 s, -0.000018 s, × 0.9996, 10 µs/rev
pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 6780 revs, 0.087953 s, 0.088090 s, +0.000137 s, × 1.0016, 12 µs/rev
pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 5441 revs, 0.062902 s, 0.062079 s, -0.000823 s, × 0.9869, 11 µs/rev
pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 43645 revs, 0.679234 s, 0.635337 s, -0.043897 s, × 0.9354, 14 µs/rev
pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 2 revs, 0.013095 s, 0.013262 s, +0.000167 s, × 1.0128, 6631 µs/rev
pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 11316 revs, 0.120910 s, 0.120085 s, -0.000825 s, × 0.9932, 10 µs/rev
netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 2 revs, 0.000087 s, 0.000085 s, -0.000002 s, × 0.9770, 42 µs/rev
netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 2 revs, 0.000107 s, 0.000110 s, +0.000003 s, × 1.0280, 55 µs/rev
netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 3 revs, 0.000186 s, 0.000177 s, -0.000009 s, × 0.9516, 59 µs/rev
netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 9 revs, 0.000754 s, 0.000743 s, -0.000011 s, × 0.9854, 82 µs/rev
netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 1421 revs, 0.010443 s, 0.010168 s, -0.000275 s, × 0.9737, 7 µs/rev
netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 1533 revs, 0.015697 s, 0.015946 s, +0.000249 s, × 1.0159, 10 µs/rev
netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 5750 revs, 0.063528 s, 0.062712 s, -0.000816 s, × 0.9872, 10 µs/rev
netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 66949 revs, 0.545515 s, 0.523832 s, -0.021683 s, × 0.9603, 7 µs/rev
mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 2 revs, 0.000089 s, 0.000090 s, +0.000001 s, × 1.0112, 45 µs/rev
mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 8 revs, 0.000265 s, 0.000264 s, -0.000001 s, × 0.9962, 33 µs/rev
mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 9 revs, 0.000381 s, 0.000187 s, -0.000194 s, × 0.4908, 20 µs/rev
mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 7 revs, 0.000672 s, 0.000665 s, -0.000007 s, × 0.9896, 95 µs/rev
mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 3 revs, 0.003497 s, 0.003556 s, +0.000059 s, × 1.0169, 1185 µs/rev
mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 6 revs, 0.073204 s, 0.071345 s, -0.001859 s, × 0.9746, 11890 µs/rev
mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 1593 revs, 0.006482 s, 0.006551 s, +0.000069 s, × 1.0106, 4 µs/rev
mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 41 revs, 0.005066 s, 0.005078 s, +0.000012 s, × 1.0024, 123 µs/rev
mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 7839 revs, 0.065707 s, 0.065823 s, +0.000116 s, × 1.0018, 8 µs/rev
mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 615 revs, 0.026800 s, 0.027050 s, +0.000250 s, × 1.0093, 43 µs/rev
mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 30263 revs, 0.203856 s, 0.202443 s, -0.001413 s, × 0.9931, 6 µs/rev
mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 153721 revs, 1.293394 s, 1.261583 s, -0.031811 s, × 0.9754, 8 µs/rev
mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 204976 revs, 1.698239 s, 1.643869 s, -0.054370 s, × 0.9680, 8 µs/rev
mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 2 revs, 0.000875 s, 0.000868 s, -0.000007 s, × 0.9920, 434 µs/rev
mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 2 revs, 0.000891 s, 0.000887 s, -0.000004 s, × 0.9955, 443 µs/rev
mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 4 revs, 0.000292 s, 0.000168 s, -0.000124 s, × 0.5753, 42 µs/rev
mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 2 revs, 0.003939 s, 0.001160 s, -0.002779 s, × 0.2945, 580 µs/rev
mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 1 revs, 0.033027 s, 0.033016 s, -0.000011 s, × 0.9997, 33016 µs/rev
mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 6 revs, 0.073703 s, 0.073312 s, -0.39ae31 s, × 0.9947, 12218 µs/rev
mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 1593 revs, 0.006469 s, 0.006485 s, +0.000016 s, × 1.0025, 4 µs/rev
mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 41 revs, 0.005278 s, 0.005494 s, +0.000216 s, × 1.0409, 134 µs/rev
mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 6657 revs, 0.064995 s, 0.064879 s, -0.000116 s, × 0.9982, 9 µs/rev
mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 40314 revs, 0.301041 s, 0.301469 s, +0.000428 s, × 1.0014, 7 µs/rev
mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 38690 revs, 0.285575 s, 0.297113 s, +0.011538 s, × 1.0404, 7 µs/rev
mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 8598 revs, 0.085597 s, 0.085890 s, +0.000293 s, × 1.0034, 9 µs/rev
mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 615 revs, 0.027118 s, 0.027718 s, +0.000600 s, × 1.0221, 45 µs/rev
mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 97052 revs, 2.119204 s, 2.048949 s, -0.070255 s, × 0.9668, 21 µs/rev
mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 52031 revs, 0.701479 s, 0.685924 s, -0.015555 s, × 0.9778, 13 µs/rev
mozilla-try x00000_revs_x_added_0_copies 6a320851d377 1ebb79acd503 : 363753 revs, 4.482399 s, 4.482891 s, +0.000492 s, × 1.0001, 12 µs/rev
mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 34414 revs, 0.574082 s, 0.577633 s, +0.003551 s, × 1.0062, 16 µs/rev
mozilla-try x00000_revs_x_added_x_copies 5173c4b6f97c 95d83ee7242d : 362229 revs, 4.480366 s, 4.397816 s, -0.082550 s, × 0.9816, 12 µs/rev
mozilla-try x00000_revs_x000_added_x_copies 9126823d0e9c ca82787bb23c : 359344 revs, 4.369070 s, 4.370538 s, +0.001468 s, × 1.0003, 12 µs/rev
mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 192665 revs, 1.592506 s, 1.570439 s, -0.022067 s, × 0.9861, 8 µs/rev
mozilla-try x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 228985 revs, 87.824489 s, 88.388512 s, +0.564023 s, × 1.0064, 386 µs/rev
mozilla-try x00000_revs_x00000_added_x000_copies 9b2a99adc05e 8e29777b48e6 : 382065 revs, 43.304637 s, 34.443661 s, -8.860976 s, × 0.7954, 90 µs/rev
private : 459513 revs, 33.853687 s, 27.370148 s, -6.483539 s, × 0.8085, 59 µs/rev
Differential Revision: https://phab.mercurial-scm.org/D9653
author | Pierre-Yves David <pierre-yves.david@octobus.net> |
---|---|
date | Wed, 16 Dec 2020 11:11:05 +0100 |
parents | e948ad0dcbe2 |
children | 86ee73018e62 |
line wrap: on
line source
#testcases filelog compatibility changeset sidedata $ cat >> $HGRCPATH << EOF > [extensions] > rebase= > [alias] > l = log -G -T '{rev} {desc}\n{files}\n' > EOF #if compatibility $ cat >> $HGRCPATH << EOF > [experimental] > copies.read-from = compatibility > EOF #endif #if changeset $ cat >> $HGRCPATH << EOF > [experimental] > copies.read-from = changeset-only > copies.write-to = changeset-only > EOF #endif #if sidedata $ cat >> $HGRCPATH << EOF > [format] > exp-use-copies-side-data-changeset = yes > EOF #endif $ REPONUM=0 $ newrepo() { > cd $TESTTMP > REPONUM=`expr $REPONUM + 1` > hg init repo-$REPONUM > cd repo-$REPONUM > } Simple rename case $ newrepo $ echo x > x $ hg ci -Aqm 'add x' $ hg mv x y $ hg debugp1copies x -> y $ hg debugp2copies $ hg ci -m 'rename x to y' $ hg l @ 1 rename x to y | x y o 0 add x x $ hg debugp1copies -r 1 x -> y $ hg debugpathcopies 0 1 x -> y $ hg debugpathcopies 1 0 y -> x Test filtering copies by path. We do filtering by destination. $ hg debugpathcopies 0 1 x $ hg debugpathcopies 1 0 x y -> x $ hg debugpathcopies 0 1 y x -> y $ hg debugpathcopies 1 0 y Copies not including commit changes $ newrepo $ echo x > x $ hg ci -Aqm 'add x' $ hg mv x y $ hg debugpathcopies . . $ hg debugpathcopies . 'wdir()' x -> y $ hg debugpathcopies 'wdir()' . y -> x Copy a file onto another file $ newrepo $ echo x > x $ echo y > y $ hg ci -Aqm 'add x and y' $ hg cp -f x y $ hg debugp1copies x -> y $ hg debugp2copies $ hg ci -m 'copy x onto y' $ hg l @ 1 copy x onto y | y o 0 add x and y x y $ hg debugp1copies -r 1 x -> y $ hg debugpathcopies 0 1 x -> y (no-filelog !) $ hg debugpathcopies 0 1 --config devel.copy-tracing.trace-all-files=yes x -> y Copy a file onto another file with same content. If metadata is stored in changeset, this does not produce a new filelog entry. The changeset's "files" entry should still list the file. $ newrepo $ echo x > x $ echo x > x2 $ hg ci -Aqm 'add x and x2 with same content' $ hg cp -f x x2 $ hg ci -m 'copy x onto x2' $ hg l @ 1 copy x onto x2 | x2 o 0 add x and x2 with same content x x2 $ hg debugp1copies -r 1 x -> x2 $ hg debugpathcopies 0 1 x -> x2 (no-filelog !) $ hg debugpathcopies 0 1 --config devel.copy-tracing.trace-all-files=yes x -> x2 Rename file in a loop: x->y->z->x $ newrepo $ echo x > x $ hg ci -Aqm 'add x' $ hg mv x y $ hg debugp1copies x -> y $ hg debugp2copies $ hg ci -m 'rename x to y' $ hg mv y z $ hg ci -m 'rename y to z' $ hg mv z x $ hg ci -m 'rename z to x' $ hg l @ 3 rename z to x | x z o 2 rename y to z | y z o 1 rename x to y | x y o 0 add x x $ hg debugpathcopies 0 3 Copy x to z, then remove z, then copy x2 (same content as x) to z. With copy metadata in the changeset, the two copies here will have the same filelog entry, so ctx['z'].introrev() might point to the first commit that added the file. We should still report the copy as being from x2. $ newrepo $ echo x > x $ echo x > x2 $ hg ci -Aqm 'add x and x2 with same content' $ hg cp x z $ hg ci -qm 'copy x to z' $ hg rm z $ hg ci -m 'remove z' $ hg cp x2 z $ hg ci -m 'copy x2 to z' $ hg l @ 3 copy x2 to z | z o 2 remove z | z o 1 copy x to z | z o 0 add x and x2 with same content x x2 $ hg debugp1copies -r 3 x2 -> z $ hg debugpathcopies 0 3 x2 -> z Create x and y, then rename them both to the same name, but on different sides of a fork $ newrepo $ echo x > x $ echo y > y $ hg ci -Aqm 'add x and y' $ hg mv x z $ hg ci -qm 'rename x to z' $ hg co -q 0 $ hg mv y z $ hg ci -qm 'rename y to z' $ hg l @ 2 rename y to z | y z | o 1 rename x to z |/ x z o 0 add x and y x y $ hg debugpathcopies 1 2 z -> x y -> z Fork renames x to y on one side and removes x on the other $ newrepo $ echo x > x $ hg ci -Aqm 'add x' $ hg mv x y $ hg ci -m 'rename x to y' $ hg co -q 0 $ hg rm x $ hg ci -m 'remove x' created new head $ hg l @ 2 remove x | x | o 1 rename x to y |/ x y o 0 add x x $ hg debugpathcopies 1 2 Merge rename from other branch $ newrepo $ echo x > x $ hg ci -Aqm 'add x' $ hg mv x y $ hg ci -m 'rename x to y' $ hg co -q 0 $ echo z > z $ hg ci -Aqm 'add z' $ hg merge -q 1 $ hg debugp1copies $ hg debugp2copies $ hg ci -m 'merge rename from p2' $ hg l @ 3 merge rename from p2 |\ | o 2 add z | | z o | 1 rename x to y |/ x y o 0 add x x Perhaps we should indicate the rename here, but `hg status` is documented to be weird during merges, so... $ hg debugp1copies -r 3 $ hg debugp2copies -r 3 $ hg debugpathcopies 0 3 x -> y $ hg debugpathcopies 1 2 y -> x $ hg debugpathcopies 1 3 $ hg debugpathcopies 2 3 x -> y Copy file from either side in a merge $ newrepo $ echo x > x $ hg ci -Aqm 'add x' $ hg co -q null $ echo y > y $ hg ci -Aqm 'add y' $ hg merge -q 0 $ hg cp y z $ hg debugp1copies y -> z $ hg debugp2copies $ hg ci -m 'copy file from p1 in merge' $ hg co -q 1 $ hg merge -q 0 $ hg cp x z $ hg debugp1copies $ hg debugp2copies x -> z $ hg ci -qm 'copy file from p2 in merge' $ hg l @ 3 copy file from p2 in merge |\ z +---o 2 copy file from p1 in merge | |/ z | o 1 add y | y o 0 add x x $ hg debugp1copies -r 2 y -> z $ hg debugp2copies -r 2 $ hg debugpathcopies 1 2 y -> z $ hg debugpathcopies 0 2 $ hg debugp1copies -r 3 $ hg debugp2copies -r 3 x -> z $ hg debugpathcopies 1 3 $ hg debugpathcopies 0 3 x -> z Copy file that exists on both sides of the merge, same content on both sides $ newrepo $ echo x > x $ hg ci -Aqm 'add x on branch 1' $ hg co -q null $ echo x > x $ hg ci -Aqm 'add x on branch 2' $ hg merge -q 0 $ hg cp x z $ hg debugp1copies x -> z $ hg debugp2copies $ hg ci -qm 'merge' $ hg l @ 2 merge |\ z | o 1 add x on branch 2 | x o 0 add x on branch 1 x $ hg debugp1copies -r 2 x -> z $ hg debugp2copies -r 2 It's a little weird that it shows up on both sides $ hg debugpathcopies 1 2 x -> z $ hg debugpathcopies 0 2 x -> z (filelog !) Copy file that exists on both sides of the merge, different content $ newrepo $ echo branch1 > x $ hg ci -Aqm 'add x on branch 1' $ hg co -q null $ echo branch2 > x $ hg ci -Aqm 'add x on branch 2' $ hg merge -q 0 warning: conflicts while merging x! (edit, then use 'hg resolve --mark') [1] $ echo resolved > x $ hg resolve -m x (no more unresolved files) $ hg cp x z $ hg debugp1copies x -> z $ hg debugp2copies $ hg ci -qm 'merge' $ hg l @ 2 merge |\ x z | o 1 add x on branch 2 | x o 0 add x on branch 1 x $ hg debugp1copies -r 2 x -> z (changeset !) x -> z (sidedata !) $ hg debugp2copies -r 2 x -> z (no-changeset no-sidedata !) $ hg debugpathcopies 1 2 x -> z (changeset !) x -> z (sidedata !) $ hg debugpathcopies 0 2 x -> z (no-changeset no-sidedata !) Copy x->y on one side of merge and copy x->z on the other side. Pathcopies from one parent of the merge to the merge should include the copy from the other side. $ newrepo $ echo x > x $ hg ci -Aqm 'add x' $ hg cp x y $ hg ci -qm 'copy x to y' $ hg co -q 0 $ hg cp x z $ hg ci -qm 'copy x to z' $ hg merge -q 1 $ hg ci -m 'merge copy x->y and copy x->z' $ hg l @ 3 merge copy x->y and copy x->z |\ | o 2 copy x to z | | z o | 1 copy x to y |/ y o 0 add x x $ hg debugp1copies -r 3 $ hg debugp2copies -r 3 $ hg debugpathcopies 2 3 x -> y $ hg debugpathcopies 1 3 x -> z Copy x to y on one side of merge, create y and rename to z on the other side. $ newrepo $ echo x > x $ hg ci -Aqm 'add x' $ hg cp x y $ hg ci -qm 'copy x to y' $ hg co -q 0 $ echo y > y $ hg ci -Aqm 'add y' $ hg mv y z $ hg ci -m 'rename y to z' $ hg merge -q 1 $ hg ci -m 'merge' $ hg l @ 4 merge |\ | o 3 rename y to z | | y z | o 2 add y | | y o | 1 copy x to y |/ y o 0 add x x $ hg debugp1copies -r 3 y -> z $ hg debugp2copies -r 3 $ hg debugpathcopies 2 3 y -> z $ hg debugpathcopies 1 3 y -> z (no-filelog !) Create x and y, then rename x to z on one side of merge, and rename y to z and modify z on the other side. When storing copies in the changeset, we don't filter out copies whose target was created on the other side of the merge. $ newrepo $ echo x > x $ echo y > y $ hg ci -Aqm 'add x and y' $ hg mv x z $ hg ci -qm 'rename x to z' $ hg co -q 0 $ hg mv y z $ hg ci -qm 'rename y to z' $ echo z >> z $ hg ci -m 'modify z' $ hg merge -q 1 warning: conflicts while merging z! (edit, then use 'hg resolve --mark') [1] $ echo z > z $ hg resolve -qm z $ hg ci -m 'merge 1 into 3' Try merging the other direction too $ hg co -q 1 $ hg merge -q 3 warning: conflicts while merging z! (edit, then use 'hg resolve --mark') [1] $ echo z > z $ hg resolve -qm z $ hg ci -m 'merge 3 into 1' created new head $ hg l @ 5 merge 3 into 1 |\ z +---o 4 merge 1 into 3 | |/ z | o 3 modify z | | z | o 2 rename y to z | | y z o | 1 rename x to z |/ x z o 0 add x and y x y $ hg debugpathcopies 1 4 y -> z (no-filelog !) $ hg debugpathcopies 2 4 x -> z (no-filelog !) $ hg debugpathcopies 0 4 x -> z (filelog !) y -> z (no-filelog !) $ hg debugpathcopies 1 5 y -> z (no-filelog !) $ hg debugpathcopies 2 5 x -> z (no-filelog !) $ hg debugpathcopies 0 5 x -> z Create x and y, then remove y and rename x to y on one side of merge, and modify x on the other side. The modification to x from the second side should be propagated to y. $ newrepo $ echo original > x $ hg add x $ echo unrelated > y $ hg add y $ hg commit -m 'add x and y' $ hg remove y $ hg commit -m 'remove y' $ hg rename x y $ hg commit -m 'rename x to y' $ hg checkout -q 0 $ echo modified > x $ hg commit -m 'modify x' created new head $ hg l @ 3 modify x | x | o 2 rename x to y | | x y | o 1 remove y |/ y o 0 add x and y x y #if filelog $ hg merge 2 file 'x' was deleted in other [merge rev] but was modified in local [working copy]. You can use (c)hanged version, (d)elete, or leave (u)nresolved. What do you want to do? u 1 files updated, 0 files merged, 0 files removed, 1 files unresolved use 'hg resolve' to retry unresolved file merges or 'hg merge --abort' to abandon [1] This should ideally be "modified", but we will probably not be able to fix that in the filelog case. $ cat y original #else $ hg merge 2 merging x and y to y 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ cat y modified #endif Same as above, but in the opposite direction #if filelog $ hg co -qC 2 $ hg merge 3 file 'x' was deleted in local [working copy] but was modified in other [merge rev]. You can use (c)hanged version, leave (d)eleted, or leave (u)nresolved. What do you want to do? u 0 files updated, 0 files merged, 0 files removed, 1 files unresolved use 'hg resolve' to retry unresolved file merges or 'hg merge --abort' to abandon [1] BROKEN: should be "modified" $ cat y original #else $ hg co -qC 2 $ hg merge 3 merging y and x to y 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ cat y modified #endif Create x and y, then rename x to z on one side of merge, and rename y to z and then delete z on the other side. $ newrepo $ echo x > x $ echo y > y $ hg ci -Aqm 'add x and y' $ hg mv x z $ hg ci -qm 'rename x to z' $ hg co -q 0 $ hg mv y z $ hg ci -qm 'rename y to z' $ hg rm z $ hg ci -m 'delete z' $ hg merge -q 1 $ echo z > z $ hg ci -m 'merge 1 into 3' Try merging the other direction too $ hg co -q 1 $ hg merge -q 3 $ echo z > z $ hg ci -m 'merge 3 into 1' created new head $ hg l @ 5 merge 3 into 1 |\ z +---o 4 merge 1 into 3 | |/ z | o 3 delete z | | z | o 2 rename y to z | | y z o | 1 rename x to z |/ x z o 0 add x and y x y $ hg debugpathcopies 1 4 $ hg debugpathcopies 2 4 x -> z (no-filelog !) $ hg debugpathcopies 0 4 x -> z (no-changeset no-compatibility !) $ hg debugpathcopies 1 5 $ hg debugpathcopies 2 5 x -> z (no-filelog !) $ hg debugpathcopies 0 5 x -> z Test for a case in fullcopytracing algorithm where neither of the merging csets is a descendant of the merge base. This test reflects that the algorithm correctly finds the copies: $ cat >> $HGRCPATH << EOF > [experimental] > evolution.createmarkers=True > evolution.allowunstable=True > EOF $ newrepo $ echo a > a $ hg add a $ hg ci -m "added a" $ echo b > b $ hg add b $ hg ci -m "added b" $ hg mv b b1 $ hg ci -m "rename b to b1" $ hg up ".^" 1 files updated, 0 files merged, 1 files removed, 0 files unresolved $ echo d > d $ hg add d $ hg ci -m "added d" created new head $ echo baba >> b $ hg ci --amend -m "added d, modified b" $ hg l --hidden @ 4 added d, modified b | b d | x 3 added d |/ d | o 2 rename b to b1 |/ b b1 o 1 added b | b o 0 added a a Grafting revision 4 on top of revision 2, showing that it respect the rename: $ hg up 2 -q $ hg graft -r 4 --base 3 --hidden grafting 4:af28412ec03c "added d, modified b" (tip) (no-changeset !) grafting 4:6325ca0b7a1c "added d, modified b" (tip) (changeset !) merging b1 and b to b1 $ hg l -l1 -p @ 5 added d, modified b | b1 ~ diff -r 5a4825cc2926 -r 94a2f1a0e8e2 b1 (no-changeset !) ~ diff -r 0a0ed3b3251c -r d544fb655520 b1 (changeset !) --- a/b1 Thu Jan 01 00:00:00 1970 +0000 +++ b/b1 Thu Jan 01 00:00:00 1970 +0000 @@ -1,1 +1,2 @@ b +baba Test to make sure that fullcopytracing algorithm doesn't fail when neither of the merging csets is a descendant of the base. ------------------------------------------------------------------------------------------------- $ newrepo $ echo a > a $ hg add a $ hg ci -m "added a" $ echo b > b $ hg add b $ hg ci -m "added b" $ echo foobar > willconflict $ hg add willconflict $ hg ci -m "added willconflict" $ echo c > c $ hg add c $ hg ci -m "added c" $ hg l @ 3 added c | c o 2 added willconflict | willconflict o 1 added b | b o 0 added a a $ hg up ".^^" 0 files updated, 0 files merged, 2 files removed, 0 files unresolved $ echo d > d $ hg add d $ hg ci -m "added d" created new head $ echo barfoo > willconflict $ hg add willconflict $ hg ci --amend -m "added willconflict and d" $ hg l @ 5 added willconflict and d | d willconflict | o 3 added c | | c | o 2 added willconflict |/ willconflict o 1 added b | b o 0 added a a $ hg rebase -r . -d 2 -t :other rebasing 5:5018b1509e94 tip "added willconflict and d" (no-changeset !) rebasing 5:af8d273bf580 tip "added willconflict and d" (changeset !) $ hg up 3 -q $ hg l --hidden o 6 added willconflict and d | d willconflict | x 5 added willconflict and d | | d willconflict | | x 4 added d | |/ d +---@ 3 added c | | c o | 2 added willconflict |/ willconflict o 1 added b | b o 0 added a a Now if we trigger a merge between revision 3 and 6 using base revision 4, neither of the merging csets will be a descendant of the base revision: $ hg graft -r 6 --base 4 --hidden -t :other grafting 6:99802e4f1e46 "added willconflict and d" (tip) (no-changeset !) grafting 6:b19f0df72728 "added willconflict and d" (tip) (changeset !)