This is an archive of the discontinued Mercurial Phabricator instance.

Differential D9609

test-copies: add test chaining multiple merges
ClosedPublic

Authored by marmoute on Dec 15 2020, 4:07 AM.

Details

Reviewers
Alphare
Group Reviewers
hg-reviewers
Commits
rHGfbc466484fc3: test-copies: add test chaining multiple merges
rHG66366987732a: test-copies: add test chaining multiple merges
Summary

Right now, the copy tracing logic take the right decision for merges, but it
does not keep track of the right information about these decision and can fall
into later traps. We start with highlighting this possibility by adding new
tests, and we will fix them later.

Check the inline test documentation for details.

Diff Detail

Repository
rHG Mercurial
Branch
default
Lint
No Linters Available
Unit
No Unit Test Coverage

Event Timeline

marmoute created this revision.Dec 15 2020, 4:07 AM
baymax updated this revision to Diff 24372.Dec 17 2020, 4:04 PM

✅ refresh by Heptapod after a successful CI run (🐙 💚)

baymax updated this revision to Diff 24399.Dec 18 2020, 9:12 AM

✅ refresh by Heptapod after a successful CI run (🐙 💚)

baymax updated this revision to Diff 24406.Dec 18 2020, 9:31 AM

✅ refresh by Heptapod after a successful CI run (🐙 💚)

baymax updated this revision to Diff 24414.Dec 18 2020, 9:54 AM

✅ refresh by Heptapod after a successful CI run (🐙 💚)

baymax updated this revision to Diff 24452.Dec 21 2020, 3:00 AM

✅ refresh by Heptapod after a successful CI run (🐙 💚)

pulkit added a subscriber: pulkit.Dec 28 2020, 3:32 AM
pulkit added inline comments.
tests/test-copies-chain-merge.t
1937

Shouldn't this and similar one above too be marked as known-bad-output?

marmoute added inline comments.Jan 5 2021, 2:50 AM
tests/test-copies-chain-merge.t
1937

Why should they be? This is the expected output for the filelog based logic.

pulkit added inline comments.Jan 5 2021, 2:53 AM
tests/test-copies-chain-merge.t
1937

I thought we can use known-bad-output for expected buggy output too.

marmoute added inline comments.Jan 5 2021, 2:58 AM
tests/test-copies-chain-merge.t
1937

The logic behind the filelog output is not "buggy" it simply use a different (more arbitrary) tie breaking mechanism that is stable regardless of the p1/p2 order. The behavior of the changeset centric algorithm is more "predictable", a hence a bit better in my opinion, however, the filelog one have been around since for-ever, so lets not touch it.

marmoute added inline comments.Jan 5 2021, 3:28 AM
tests/test-copies-chain-merge.t
1375

This comment is relevant to the conversation we are having.

baymax updated this revision to Diff 24568.Jan 5 2021, 3:37 AM

✅ refresh by Heptapod after a successful CI run (🐙 💚)

baymax updated this revision to Diff 24591.Jan 5 2021, 9:01 AM

✅ refresh by Heptapod after a successful CI run (🐙 💚)

Alphare accepted this revision.Jan 5 2021, 11:47 AM
• ulrickaka added a subscriber: • ulrickaka.Jan 5 2021, 2:06 PM

Leather Motorcycle Jackets for Women
Find stylish motorcycle jackets for women at Wilsons Leather. Our collection feature quality leather moto jackets in a variety of colors and styles

nikkireed1122 added a subscriber: nikkireed1122.Jan 5 2021, 2:18 PM

Lucidchart Group Buy
is the best online graphing tool that makes drawing charts quick and easy. Quick flowcharts, company graphs, wireframes, UML, mind

marmoute edited parent revisions, added: D10047: test-copies: add subcase titles for various "conflicting" information variant; removed: D9587: test-copies: reinstall initial identical (empty) files for chained copied.Feb 22 2021, 9:34 AM
marmoute retitled this revision from copies-test: add test chaining multiple merge to test-copies: add test chaining multiple merges.
marmoute updated this revision to Diff 25721.
baymax updated this revision to Diff 25762.Feb 22 2021, 11:34 AM

✅ refresh by Heptapod after a successful CI run (🐙 💚)

marmoute added a commit: rHG66366987732a: test-copies: add test chaining multiple merges.Feb 24 2021, 10:56 AM
This revision was not accepted when it landed; it landed in state Needs Review.
Closed by commit rHG66366987732a: test-copies: add test chaining multiple merges (authored by marmoute). · Explain Why
This revision was automatically updated to reflect the committed changes.

Revision Contents
Changeset List

PathPackages
Mtests/test-copies-chain-merge.t (196 lines)

Diff 24452

tests/test-copies-chain-merge.t

| | | |
o | 2 i-2: c -move-> d o | 2 i-2: c -move-> d
| | | |
o | 1 i-1: a -move-> c o | 1 i-1: a -move-> c
|/ |/
o 0 i-0 initial commit: a b h o 0 i-0 initial commit: a b h
Decision from previous merge are properly chained with later merge
------------------------------------------------------------------
Subcase: chaining conflicting rename resolution
```````````````````````````````````````````````
The "mAEm" and "mEAm" case create a rename tracking conflict on file 'f'. We
add more change on the respective branch and merge again. These second merge
does not involve the file 'f' and the arbitration done within "mAEm" and "mEA"
about that file should stay unchanged.
(extra unrelated changes)
$ hg up 'desc("a-2")'
2 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ echo j > unrelated-j
$ hg add unrelated-j
$ hg ci -m 'j-1: unrelated changes (based on the "a" series of changes)'
created new head
$ hg up 'desc("e-2")'
2 files updated, 0 files merged, 2 files removed, 0 files unresolved (no-changeset !)
1 files updated, 0 files merged, 2 files removed, 0 files unresolved (changeset !)
$ echo k > unrelated-k
$ hg add unrelated-k
$ hg ci -m 'k-1: unrelated changes (based on "e" changes)'
created new head
(merge variant 1)
$ hg up 'desc("mAEm")'
1 files updated, 0 files merged, 2 files removed, 0 files unresolved (no-changeset !)
0 files updated, 0 files merged, 2 files removed, 0 files unresolved (changeset !)
$ hg merge 'desc("k-1")'
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg ci -m 'mAE,Km: simple merge'
(merge variant 2)
$ hg up 'desc("k-1")'
2 files updated, 0 files merged, 0 files removed, 0 files unresolved (no-changeset !)
1 files updated, 0 files merged, 0 files removed, 0 files unresolved (changeset !)
$ hg merge 'desc("mAEm")'
1 files updated, 0 files merged, 1 files removed, 0 files unresolved (no-changeset !)
0 files updated, 0 files merged, 1 files removed, 0 files unresolved (changeset !)
(branch merge, don't forget to commit)
$ hg ci -m 'mK,AEm: simple merge'
created new head
(merge variant 3)
$ hg up 'desc("mEAm")'
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg merge 'desc("j-1")'
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg ci -m 'mEA,Jm: simple merge'
(merge variant 4)
$ hg up 'desc("j-1")'
2 files updated, 0 files merged, 0 files removed, 0 files unresolved (no-changeset !)
1 files updated, 0 files merged, 0 files removed, 0 files unresolved (changeset !)
$ hg merge 'desc("mEAm")'
1 files updated, 0 files merged, 1 files removed, 0 files unresolved (no-changeset !)
0 files updated, 0 files merged, 1 files removed, 0 files unresolved (changeset !)
(branch merge, don't forget to commit)
$ hg ci -m 'mJ,EAm: simple merge'
created new head
$ hg log -G --rev '::(desc("mAE,Km") + desc("mK,AEm") + desc("mEA,Jm") + desc("mJ,EAm"))'
@ 42 mJ,EAm: simple merge
|\
+---o 41 mEA,Jm: simple merge
| |/
| | o 40 mK,AEm: simple merge
| | |\
| | +---o 39 mAE,Km: simple merge
| | | |/
| | | o 38 k-1: unrelated changes (based on "e" changes)
| | | |
| o | | 37 j-1: unrelated changes (based on the "a" series of changes)
| | | |
o-----+ 20 mEAm-0 simple merge - the other way
|/ / /
| o / 19 mAEm-0 simple merge - one way
|/|/
| o 10 e-2 g -move-> f
| |
| o 9 e-1 b -move-> g
| |
o | 4 a-2: e -move-> f
| |
o | 3 a-1: d -move-> e
|/
o 2 i-2: c -move-> d
|
o 1 i-1: a -move-> c
|
o 0 i-0 initial commit: a b h
Summary of all created cases Summary of all created cases
---------------------------- ----------------------------
$ hg up --quiet null $ hg up --quiet null
(This exists to help keeping a compact list of the various cases we have built) (This exists to help keeping a compact list of the various cases we have built)
$ hg log -T '{desc|firstline}\n'| sort $ hg log -T '{desc|firstline}\n'| sort
a-1: d -move-> e a-1: d -move-> e
a-2: e -move-> f a-2: e -move-> f
b-1: b update b-1: b update
c-1 delete d c-1 delete d
d-1 delete d d-1 delete d
d-2 re-add d d-2 re-add d
e-1 b -move-> g e-1 b -move-> g
e-2 g -move-> f e-2 g -move-> f
f-1: rename h -> i f-1: rename h -> i
f-2: rename i -> d f-2: rename i -> d
g-1: update d g-1: update d
h-1: b -(move)-> d h-1: b -(move)-> d
i-0 initial commit: a b h i-0 initial commit: a b h
i-1: a -move-> c i-1: a -move-> c
i-2: c -move-> d i-2: c -move-> d
j-1: unrelated changes (based on the "a" series of changes)
k-1: unrelated changes (based on "e" changes)
mABm-0 simple merge - the other way mABm-0 simple merge - the other way
mAE,Km: simple merge
mAEm-0 simple merge - one way mAEm-0 simple merge - one way
mBAm-0 simple merge - one way mBAm-0 simple merge - one way
mBC-revert-m-0 mBC-revert-m-0
mBCm-0 simple merge - one way mBCm-0 simple merge - one way
mBCm-1 re-add d mBCm-1 re-add d
mBDm-0 simple merge - one way mBDm-0 simple merge - one way
mBFm-0 simple merge - one way mBFm-0 simple merge - one way
mCB-revert-m-0 mCB-revert-m-0
mCBm-0 simple merge - the other way mCBm-0 simple merge - the other way
mCBm-1 re-add d mCBm-1 re-add d
mCGm-0 mCGm-0
mCH-delete-before-conflict-m-0 mCH-delete-before-conflict-m-0
mDBm-0 simple merge - the other way mDBm-0 simple merge - the other way
mDGm-0 simple merge - one way mDGm-0 simple merge - one way
mEA,Jm: simple merge
mEAm-0 simple merge - the other way mEAm-0 simple merge - the other way
mFBm-0 simple merge - the other way mFBm-0 simple merge - the other way
mFGm-0 simple merge - one way mFGm-0 simple merge - one way
mGCm-0 mGCm-0
mGDm-0 simple merge - the other way mGDm-0 simple merge - the other way
mGFm-0 simple merge - the other way mGFm-0 simple merge - the other way
mHC-delete-before-conflict-m-0 mHC-delete-before-conflict-m-0
mJ,EAm: simple merge
mK,AEm: simple merge
Test that sidedata computations during upgrades are correct Test that sidedata computations during upgrades are correct
=========================================================== ===========================================================
We upgrade a repository that is not using sidedata (the filelog case) and We upgrade a repository that is not using sidedata (the filelog case) and
check that the same side data have been generated as if they were computed at check that the same side data have been generated as if they were computed at
commit time. commit time.
##### revision 35 ##### ##### revision 35 #####
1 sidedata entries 1 sidedata entries
entry-0014 size 4 entry-0014 size 4
'\x00\x00\x00\x00' '\x00\x00\x00\x00'
##### revision 36 ##### ##### revision 36 #####
1 sidedata entries 1 sidedata entries
entry-0014 size 4 entry-0014 size 4
'\x00\x00\x00\x00' '\x00\x00\x00\x00'
##### revision 37 #####
1 sidedata entries
entry-0014 size 24
'\x00\x00\x00\x01\x04\x00\x00\x00\x0b\x00\x00\x00\x00unrelated-j'
added : unrelated-j, ;
##### revision 38 #####
1 sidedata entries
entry-0014 size 24
'\x00\x00\x00\x01\x04\x00\x00\x00\x0b\x00\x00\x00\x00unrelated-k'
added : unrelated-k, ;
##### revision 39 #####
1 sidedata entries
entry-0014 size 4
'\x00\x00\x00\x00'
##### revision 40 #####
1 sidedata entries
entry-0014 size 4
'\x00\x00\x00\x00'
##### revision 41 #####
1 sidedata entries
entry-0014 size 4
'\x00\x00\x00\x00'
##### revision 42 #####
1 sidedata entries
entry-0014 size 4
'\x00\x00\x00\x00'
#endif #endif
Test copy information chaining Test copy information chaining
============================== ==============================
Check that matching only affect the destination and not intermediate path Check that matching only affect the destination and not intermediate path
R d R d
$ hg status --copies --rev 'desc("i-2")' --rev 'desc("e-2")' $ hg status --copies --rev 'desc("i-2")' --rev 'desc("e-2")'
A f A f
b b
R b R b
# From here, we run status against revision where both source file exists. # From here, we run status against revision where both source file exists.
# #
# The filelog based implementation picks an arbitrary side based on revision # The filelog based implementation picks an arbitrary side based on revision
marmouteAuthorUnsubmitted
Done

This comment is relevant to the conversation we are having.

marmoute: This comment is relevant to the conversation we are having.
# numbers. So the same side "wins" whatever the parents order is. This is # numbers. So the same side "wins" whatever the parents order is. This is
# sub-optimal because depending on revision numbers means the result can be # sub-optimal because depending on revision numbers means the result can be
# different from one repository to the next. # different from one repository to the next.
# #
# The changeset based algorithm use the parent order to break tie on conflicting # The changeset based algorithm use the parent order to break tie on conflicting
# information and will have a different order depending on who is p1 and p2. # information and will have a different order depending on who is p1 and p2.
# That order is stable accross repositories. (data from p1 prevails) # That order is stable accross repositories. (data from p1 prevails)
$ hg status --copies --rev 'desc("c-1")' --rev 'desc("mHC-delete-before-conflict-m")' $ hg status --copies --rev 'desc("c-1")' --rev 'desc("mHC-delete-before-conflict-m")'
A d A d
b b
R b R b
$ hg status --copies --rev 'desc("h-1")' --rev 'desc("mCH-delete-before-conflict-m")' $ hg status --copies --rev 'desc("h-1")' --rev 'desc("mCH-delete-before-conflict-m")'
R a R a
$ hg status --copies --rev 'desc("h-1")' --rev 'desc("mHC-delete-before-conflict-m")' $ hg status --copies --rev 'desc("h-1")' --rev 'desc("mHC-delete-before-conflict-m")'
R a R a
Decision from previous merge are properly chained with later merge
------------------------------------------------------------------
Subcase: chaining conflicting rename resolution
```````````````````````````````````````````````
The "mAEm" and "mEAm" case create a rename tracking conflict on file 'f'. We
add more change on the respective branch and merge again. These second merge
does not involve the file 'f' and the arbitration done within "mAEm" and "mEA"
about that file should stay unchanged.
The result from mAEm is the same for the subsequent merge:
$ hg status --copies --rev 'desc("i-0")' --rev 'desc("mAEm")' f
A f
a (filelog !)
a (sidedata !)
a (upgraded !)
$ hg status --copies --rev 'desc("i-0")' --rev 'desc("mAE,Km")' f
A f
a (filelog !)
a (sidedata !)
a (upgraded !)
$ hg status --copies --rev 'desc("i-0")' --rev 'desc("mK,AEm")' f
A f
a (filelog !)
a (missing-correct-output sidedata !)
a (missing-correct-output upgraded !)
b (known-bad-output sidedata !)
b (known-bad-output upgraded !)
The result from mEAm is the same for the subsequent merge:
$ hg status --copies --rev 'desc("i-0")' --rev 'desc("mEAm")' f
A f
a (filelog !)
b (sidedata !)
b (upgraded !)
$ hg status --copies --rev 'desc("i-0")' --rev 'desc("mEA,Jm")' f
A f
a (filelog !)
b (sidedata !)
b (upgraded !)
$ hg status --copies --rev 'desc("i-0")' --rev 'desc("mJ,EAm")' f
A f
a (filelog !)
pulkitUnsubmitted
Not Done

Shouldn't this and similar one above too be marked as known-bad-output?

pulkit: Shouldn't this and similar one above too be marked as `known-bad-output`?
marmouteAuthorUnsubmitted
Done

Why should they be? This is the expected output for the filelog based logic.

marmoute: Why should they be? This is the expected output for the filelog based logic.
pulkitUnsubmitted
Not Done

I thought we can use known-bad-output for expected buggy output too.

pulkit: I thought we can use `known-bad-output` for expected buggy output too.
marmouteAuthorUnsubmitted
Done

The logic behind the filelog output is not "buggy" it simply use a different (more arbitrary) tie breaking mechanism that is stable regardless of the p1/p2 order. The behavior of the changeset centric algorithm is more "predictable", a hence a bit better in my opinion, however, the filelog one have been around since for-ever, so lets not touch it.

marmoute: The logic behind the filelog output is not "buggy" it simply use a different (more arbitrary)…
b (missing-correct-output sidedata !)
b (missing-correct-output upgraded !)
a (known-bad-output sidedata !)
a (known-bad-output upgraded !)