This is an archive of the discontinued Mercurial Phabricator instance.

Differential D9587

test-copies: reinstall initial identical (empty) files for chained copied
ClosedPublic

Authored by marmoute on Dec 14 2020, 6:17 AM.

Details

Reviewers
martinvonz
Alphare
durin42
Group Reviewers
hg-reviewers
Commits
rHG018d622e814d: test-copies: reinstall initial identical (empty) files for chained copied
Summary

This effectively back out changeset deeb215be337. Changeset deeb215be33 does not
really include a justification for its change and make mes uncomfortable. I have
been thinking about it and they are two options:

  • either having empty/full files does not make a difference, and deeb215be337 is a gratuitous changes.
  • either having empty/full files do make a difference and deeb215be33 silently change the test coverage. In such situation if we want the "not empty" case to be tested, we should add new cases to cover them

In practice, we know that the "file content did not change, but merge still need
to create a new filenode" case exists (for example if merging result in similar
content but both parent of the file need to be recorded), and that such case are
easy to miss/mess-up in the tests. Having all the file using the same (empty)
content was done on purpose to increase the coverage of such corner case.

As a result I am reinstalling the previous test situation. To
increase the coverage of some case involving content-merge in
test-copies-chain-merge.t, we will add a new, dedicated, cases later in this
series, once various cleanup and test improvement have been set in place.

This changeset starts with reinstalling the previous situation as (1) it is more
fragile, so I am more confided getting it back in the initial situation, (2) I
have specific test further down the line that are base on these one.

The next changeset will slightly alter the test to use non-empty files for these
tests (with identical content). It should help to make the initial intent "merge file with identical
content" clearer. I am still using a two steps (backout, then change content)
approach to facilitate careful validation of the output change.

Doing so has a large impact on the output of the "copy info in changeset extra" variant
added in 5e72827dae1e (2 changesets after deeb215be33). It seems to highlight
various breakage when merge without content change are involved, this is a good
example of why we want to explicitly test theses cases. Because the different
-do- matters a lot.

Fixing the "copy info in changeset extra" is not a priority here. Because (1)
this changeset does not break anything, it only highlight that they were always
broken. (2) the only people using "copy info in changeset extra" do not have
merge.

Diff Detail

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

Event Timeline

marmoute created this revision.Dec 14 2020, 6:17 AM
baymax updated this revision to Diff 24251.Dec 14 2020, 9:15 AM

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

martinvonz requested changes to this revision.Dec 15 2020, 11:37 AM
martinvonz added a subscriber: martinvonz.

I don't see how this improves testing. I won't queue it and I won't give it an accept stamp. Other reviewers can of course disagree with me.

This revision now requires changes to proceed.Dec 15 2020, 11:37 AM
baymax edited the summary of this revision. (Show Details)Dec 17 2020, 3:53 PM
baymax updated this revision to Diff 24364.

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

baymax updated this revision to Diff 24386.Dec 18 2020, 8:40 AM

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

Alphare accepted this revision.Dec 18 2020, 12:06 PM
Alphare added a subscriber: Alphare.

It looks like @marmoute has added additional justification for the change. To me, this looks like a decent strategy: prioritize the cases you know to fail, and then slowly go over the rest.
There are clearly corner-cases that we're hitting when using empty files, they're worth testing, as long as the tests for non-empty files come along in a future patch to not lose coverage one way or the other.
I have good insider information that the future patches will come in time, hehe.

martinvonz requested changes to this revision.Dec 18 2020, 1:26 PM
In D9587#145179, @Alphare wrote:

It looks like @marmoute has added additional justification for the change. To me, this looks like a decent strategy: prioritize the cases you know to fail, and then slowly go over the rest.
There are clearly corner-cases that we're hitting when using empty files, they're worth testing, as long as the tests for non-empty files come along in a future patch to not lose coverage one way or the other.
I have good insider information that the future patches will come in time, hehe.

Can we at least move it out of this series? And please do it thoroughly and thoughtfully across the entire test suite: go through the test suite and see which tests would work just as well with empty files and update all of them, and of course add duplicate versions with non-empty tests where it might matter (as it does for copy tracing without data in the filelog).

This revision now requires changes to proceed.Dec 18 2020, 1:26 PM
marmoute added a comment.Dec 19 2020, 1:09 PM
In D9587#145182, @martinvonz wrote:
In D9587#145179, @Alphare wrote:

It looks like @marmoute has added additional justification for the change. To me, this looks like a decent strategy: prioritize the cases you know to fail, and then slowly go over the rest.
There are clearly corner-cases that we're hitting when using empty files, they're worth testing, as long as the tests for non-empty files come along in a future patch to not lose coverage one way or the other.
I have good insider information that the future patches will come in time, hehe.

Can we at least move it out of this series?

This changeset is part of this series because I am adding more test down the line. And I want to restore the intended test coverage of test-copies-chain-merge.t before doing so, so that the new test have the right coverage too.

And please do it thoroughly and thoughtfully across the entire test suite: go through the test suite and see which tests would work just as well with empty files and update all of them, and of course add duplicate versions with non-empty tests where it might matter (as it does for copy tracing without data in the filelog).

As explained in this patch, I am planning for a more thoughtful review and consolidation of the test coverage of copy tracing. However bandwidth is limited and I currently focus on covering and fixing some specific cases. As explained in the first part of this reply, I am backing out a regression in test coverage as part of this focus.

baymax updated this revision to Diff 24447.Dec 21 2020, 2:43 AM

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

baymax updated this revision to Diff 24573.Jan 5 2021, 3:38 AM

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

pulkit added subscribers: mharbison72, durin42, pulkit.Jan 5 2021, 4:48 AM

I had a meeting earlier with @marmoute today and we discussed this. After my discussion and reviewing this patch, I understood:

  1. the motive is to test merging files that have same file content on both sides. So instead of empty files, we probably can have a version of this patch that writes out the same content.
  2. Having the same content is breaking tests for changeset case. Refer changes around line-354 on both sides.

The 2) part makes me think that we should have tests for merging files with the same content. I don't have a strong opinion on how that should be done[1]. @durin42 @mharbison72 thoughts on that?

@marmoute @martinvonz correct me if I got something wrong.

[1]: IIRC, I pushed Martin's original patch which added content to files and though Pierre-Yves later commented against it, I didn't understand the hidden benefit that empty files were bringing i.e. merging files with the same content

marmoute added a comment.Jan 6 2021, 1:42 PM
In D9587#146006, @pulkit wrote:

I had a meeting earlier with @marmoute today and we discussed this. After my discussion and reviewing this patch, I understood:

  1. the motive is to test merging files that have same file content on both sides. So instead of empty files, we probably can have a version of this patch that writes out the same content.

We can probably have a version of these tests using some explicite content that is indentical on purpose. That will probably requires to adjustement during some merge to make sure we keep the same content 2 content situation. I can follow up with such patch if you want. I would rather keep this one a backout of the on regressing the coverage to avoid mixing different changes.

  1. Having the same content is breaking tests for changeset case. Refer changes around line-354 on both sides.

The 2) part makes me think that we should have tests for merging files with the same content. I don't have a strong opinion on how that should be done[1]. @durin42 @mharbison72 thoughts on that?
@marmoute @martinvonz correct me if I got something wrong.

I think you got things right.

[1]: IIRC, I pushed Martin's original patch which added content to files and though Pierre-Yves later commented against it, I didn't understand the hidden benefit that empty files were bringing i.e. merging files with the same content

durin42 requested changes to this revision.Jan 11 2021, 2:25 PM

I guess I don't really understand the position of "we should back this out" particularly. Given that it's a test-only change, could we just roll-forward with the new test discussed (that is, a variant of this test with the content the same for all the files)?

AIUI that's the desired end state: a version of this test with contents-same and contents-different files, and the empty files is merely a path to having the contents-same variant. Right? I'd rather not bikeshed about the particular path function to get there, but I'm also not really interested in landing _this specific patch_ because it doesn't improve things - it's just picking the "files all match" variant rather than the "files differ" variant, but in a way that (I think?) most of us agree is worse (empty files).

So please either update this patch to introduce a non-empty matching-file version of the test, or let's drop it for now.

This revision now requires changes to proceed.Jan 11 2021, 2:25 PM
marmoute planned changes to this revision.Feb 15 2021, 10:26 AM

I finally have to get back the copy tracing test. So here is quick heads up on my current plan:

  1. backout the content change (this changeset) to get back to a previously validated state
  2. change the content of the "same-content" file while carefully making sure the test preserver their current property
  3. introduce new explicit test for the "merge different content" case.

They might be some wider rework of the tests at some point in the process (probably between 2 and 3, or after 3).

Since the compatibility changeset case runs code knowly misbehave with merge, and that they am I not aware of any plan to fix that (because the sole user-group of theses options does not use Merge), I expect them to be cumbersome to support while we refactor the tests. They often requires conditional matching of output (since they give wrong results) and their output is not really worth checking-and-preserving (since we know them to be wrong). Depending on how combersum this turn out, I might drop these cases sometwhere in the process. (Unless of course if someone can make a compelling argument of why they should be tested there).

Keep in mind that no plan survive first contact with reality. I'll ping this Diff again when I am done reworking the tests.

marmoute added a comment.Feb 18 2021, 1:52 PM
In D9587#151502, @marmoute wrote:

I finally have to get back the copy tracing test. So here is quick heads up on my current plan:

  1. backout the content change (this changeset) to get back to a previously validated state
  2. change the content of the "same-content" file while carefully making sure the test preserver their current property
  3. introduce new explicit test for the "merge different content" case.

They might be some wider rework of the tests at some point in the process (probably between 2 and 3, or after 3).
Since the compatibility changeset case runs code knowly misbehave with merge, and that they am I not aware of any plan to fix that (because the sole user-group of theses options does not use Merge), I expect them to be cumbersome to support while we refactor the tests. They often requires conditional matching of output (since they give wrong results) and their output is not really worth checking-and-preserving (since we know them to be wrong). Depending on how combersum this turn out, I might drop these cases sometwhere in the process. (Unless of course if someone can make a compelling argument of why they should be tested there).
Keep in mind that no plan survive first contact with reality. I'll ping this Diff again when I am done reworking the tests.

I have been spend a significant part of my week on this. step (1) and (2) went fine without much pain. I am now working on slowly adding variant of the test that involve merges that involves identical file. They are mostly two differents variants that seems relevant:

  1. case where the merge still involve identical files, but then introduce extra change before committing
  1. case where merge involves files with different content.

Progress are steady, but the whole mass of work is significant since validating out the output change is tedious and slow.

The "good news" is that some of the new tests already yield some bugs in the current code.

marmoute added a comment.Feb 22 2021, 8:11 AM
  1. case where the merge still involve identical files, but then introduce extra change before committing

These one reveal various issue in the merge-code (affecting filelog based copy tracing) and the associated sidedata recording (including mismatch between commit-time and upgrade-time data). This will requires more work.

In the mean time the test adding coverage for merge involving different content have been added and does not reveal any new bug. I'll send them shortly once I'll be done rebasing and retesting the multiple dozen of patch that depends on this.

marmoute retitled this revision from copies: reinstall initial empty files for chained copied to test-copies: reinstall initial identical (empty) files for chained copied.Feb 22 2021, 9:33 AM
marmoute edited the summary of this revision. (Show Details)
marmoute added a child revision: D10035: test-copies: don't use empty file for "same content" cases.
marmoute removed a child revision: D9609: test-copies: add test chaining multiple merges.
marmoute updated this revision to Diff 25707.
marmoute added a comment.Feb 22 2021, 5:53 PM

This series is ready to be re-reviewed.

(for those curious, the piece about adding and merging files with different content are in D10053 to D10059)

marmoute added a commit: rHG018d622e814d: test-copies: reinstall initial identical (empty) files for chained copied.Feb 24 2021, 10:54 AM
This revision was not accepted when it landed; it landed in state Needs Review.
Closed by commit rHG018d622e814d: test-copies: reinstall initial identical (empty) files for chained copied (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 (163 lines)

Diff 24226

tests/test-copies-chain-merge.t

#endif #endif
$ hg init repo-chain $ hg init repo-chain
$ cd repo-chain $ cd repo-chain
Add some linear rename initialy Add some linear rename initialy
$ echo a > a $ touch a b h
$ echo b > b
$ echo h > h
$ hg ci -Am 'i-0 initial commit: a b h' $ hg ci -Am 'i-0 initial commit: a b h'
adding a adding a
adding b adding b
adding h adding h
$ hg mv a c $ hg mv a c
$ hg ci -Am 'i-1: a -move-> c' $ hg ci -Am 'i-1: a -move-> c'
$ hg mv c d $ hg mv c d
$ hg ci -Am 'i-2: c -move-> d' $ hg ci -Am 'i-2: c -move-> d'
Comparing with a merge with colliding rename Comparing with a merge with colliding rename
-------------------------------------------- --------------------------------------------
- the "e-" branch renaming b to f (through 'g') - the "e-" branch renaming b to f (through 'g')
- the "a-" branch renaming d to f (through e) - the "a-" branch renaming d to f (through e)
$ hg up 'desc("a-2")' $ hg up 'desc("a-2")'
2 files updated, 0 files merged, 1 files removed, 0 files unresolved 2 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg merge 'desc("e-2")' --tool :union $ hg merge 'desc("e-2")'
merging f 1 files updated, 0 files merged, 1 files removed, 0 files unresolved (no-changeset !)
1 files updated, 0 files merged, 1 files removed, 0 files unresolved 0 files updated, 0 files merged, 1 files removed, 0 files unresolved (changeset !)
(branch merge, don't forget to commit) (branch merge, don't forget to commit)
$ hg ci -m 'mAEm-0 simple merge - one way' $ hg ci -m 'mAEm-0 simple merge - one way'
$ hg up 'desc("e-2")' $ hg up 'desc("e-2")'
2 files updated, 0 files merged, 0 files removed, 0 files unresolved 2 files updated, 0 files merged, 0 files removed, 0 files unresolved (no-changeset !)
$ hg merge 'desc("a-2")' --tool :union 1 files updated, 0 files merged, 0 files removed, 0 files unresolved (changeset !)
merging f $ hg merge 'desc("a-2")'
1 files updated, 0 files merged, 1 files removed, 0 files unresolved 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) (branch merge, don't forget to commit)
$ hg ci -m 'mEAm-0 simple merge - the other way' $ hg ci -m 'mEAm-0 simple merge - the other way'
created new head created new head
$ hg log -G --rev '::(desc("mAEm")+desc("mEAm"))' $ hg log -G --rev '::(desc("mAEm")+desc("mEAm"))'
@ 20 mEAm-0 simple merge - the other way @ 20 mEAm-0 simple merge - the other way
|\ |\
+---o 19 mAEm-0 simple merge - one way +---o 19 mAEm-0 simple merge - one way
| |/ | |/
2 files updated, 0 files merged, 1 files removed, 0 files unresolved 2 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg mv h i $ hg mv h i
$ hg commit -m "f-1: rename h -> i" $ hg commit -m "f-1: rename h -> i"
created new head created new head
$ hg mv --force i d $ hg mv --force i d
$ hg commit -m "f-2: rename i -> d" $ hg commit -m "f-2: rename i -> d"
$ hg debugindex d $ hg debugindex d
rev linkrev nodeid p1 p2 rev linkrev nodeid p1 p2
0 2 169be882533b 000000000000 000000000000 (no-changeset !) 0 2 01c2f5eabdc4 000000000000 000000000000 (no-changeset !)
0 2 b789fdd96dc2 000000000000 000000000000 (changeset !) 0 2 b80de5d13875 000000000000 000000000000 (changeset !)
1 8 b004912a8510 000000000000 000000000000 1 8 b004912a8510 000000000000 000000000000
2 22 4a067cf8965d 000000000000 000000000000 (no-changeset !) 2 22 c72365ee036f 000000000000 000000000000 (no-changeset !)
2 22 fe6f8b4f507f 000000000000 000000000000 (changeset !)
$ hg up 'desc("b-1")' $ hg up 'desc("b-1")'
3 files updated, 0 files merged, 0 files removed, 0 files unresolved 3 files updated, 0 files merged, 0 files removed, 0 files unresolved (no-changeset !)
2 files updated, 0 files merged, 0 files removed, 0 files unresolved (changeset !)
$ hg merge 'desc("f-2")' $ hg merge 'desc("f-2")'
1 files updated, 0 files merged, 1 files removed, 0 files unresolved 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) (branch merge, don't forget to commit)
$ hg ci -m 'mBFm-0 simple merge - one way' $ hg ci -m 'mBFm-0 simple merge - one way'
$ hg up 'desc("f-2")' $ hg up 'desc("f-2")'
1 files updated, 0 files merged, 0 files removed, 0 files unresolved 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg merge 'desc("b-1")' $ hg merge 'desc("b-1")'
1 files updated, 0 files merged, 0 files removed, 0 files unresolved 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit) (branch merge, don't forget to commit)
$ hg ci -m 'mFBm-0 simple merge - the other way' $ hg ci -m 'mFBm-0 simple merge - the other way'
Merge: Merge:
- one with change to a file - one with change to a file
- one deleting and recreating the file - one deleting and recreating the file
Unlike in the 'BD/DB' cases, an actual merge happened here. So we should Unlike in the 'BD/DB' cases, an actual merge happened here. So we should
consider history and rename on both branch of the merge. consider history and rename on both branch of the merge.
$ hg up 'desc("i-2")' $ hg up 'desc("i-2")'
3 files updated, 0 files merged, 0 files removed, 0 files unresolved 3 files updated, 0 files merged, 0 files removed, 0 files unresolved (no-changeset !)
2 files updated, 0 files merged, 0 files removed, 0 files unresolved (changeset !)
$ echo "some update" >> d $ echo "some update" >> d
$ hg commit -m "g-1: update d" $ hg commit -m "g-1: update d"
created new head created new head
$ hg up 'desc("d-2")' $ hg up 'desc("d-2")'
1 files updated, 0 files merged, 0 files removed, 0 files unresolved 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg merge 'desc("g-1")' --tool :union $ hg merge 'desc("g-1")' --tool :union
merging d merging d
1 files updated, 0 files merged, 0 files removed, 0 files unresolved 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
| In this case, the merge get conflicting information since on one side we have | In this case, the merge get conflicting information since on one side we have
| "a -> c -> d". and one the other one we have "h -> i -> d". | "a -> c -> d". and one the other one we have "h -> i -> d".
| |
| The current code arbitrarily pick one side | The current code arbitrarily pick one side
$ hg up 'desc("f-2")' $ hg up 'desc("f-2")'
1 files updated, 0 files merged, 1 files removed, 0 files unresolved 1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg merge 'desc("g-1")' --tool :union $ hg merge 'desc("g-1")' --tool :union
merging d merging d (no-changeset !)
1 files updated, 0 files merged, 0 files removed, 0 files unresolved 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (no-changeset !)
1 files updated, 0 files merged, 0 files removed, 0 files unresolved (changeset !)
(branch merge, don't forget to commit) (branch merge, don't forget to commit)
$ hg ci -m 'mFGm-0 simple merge - one way' $ hg ci -m 'mFGm-0 simple merge - one way'
created new head created new head
$ hg up 'desc("g-1")' $ hg up 'desc("g-1")'
2 files updated, 0 files merged, 0 files removed, 0 files unresolved 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("f-2")' --tool :union $ hg merge 'desc("f-2")' --tool :union
merging d merging d (no-changeset !)
1 files updated, 0 files merged, 1 files removed, 0 files unresolved 0 files updated, 1 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) (branch merge, don't forget to commit)
$ hg ci -m 'mGFm-0 simple merge - the other way' $ hg ci -m 'mGFm-0 simple merge - the other way'
created new head created new head
$ hg log -G --rev '::(desc("mGFm")+desc("mFGm"))' $ hg log -G --rev '::(desc("mGFm")+desc("mFGm"))'
@ 29 mGFm-0 simple merge - the other way @ 29 mGFm-0 simple merge - the other way
|\ |\
+---o 28 mFGm-0 simple merge - one way +---o 28 mFGm-0 simple merge - one way
| |/ | |/
$ hg manifest --debug --rev 'desc("mBDm-0")' | grep '644 d' $ hg manifest --debug --rev 'desc("mBDm-0")' | grep '644 d'
b004912a8510032a0350a74daa2803dadfb00e12 644 d b004912a8510032a0350a74daa2803dadfb00e12 644 d
$ hg manifest --debug --rev 'desc("mDBm-0")' | grep '644 d' $ hg manifest --debug --rev 'desc("mDBm-0")' | grep '644 d'
b004912a8510032a0350a74daa2803dadfb00e12 644 d b004912a8510032a0350a74daa2803dadfb00e12 644 d
$ hg manifest --debug --rev 'desc("d-2")' | grep '644 d' $ hg manifest --debug --rev 'desc("d-2")' | grep '644 d'
b004912a8510032a0350a74daa2803dadfb00e12 644 d b004912a8510032a0350a74daa2803dadfb00e12 644 d
$ hg manifest --debug --rev 'desc("b-1")' | grep '644 d' $ hg manifest --debug --rev 'desc("b-1")' | grep '644 d'
169be882533bc917905d46c0c951aa9a1e288dcf 644 d (no-changeset !) 01c2f5eabdc4ce2bdee42b5f86311955e6c8f573 644 d (no-changeset !)
b789fdd96dc2f3bd229c1dd8eedf0fc60e2b68e3 644 d (changeset !) b80de5d138758541c5f05265ad144ab9fa86d1db 644 d (changeset !)
$ hg debugindex d | head -n 4 $ hg debugindex d | head -n 4
rev linkrev nodeid p1 p2 rev linkrev nodeid p1 p2
0 2 169be882533b 000000000000 000000000000 (no-changeset !) 0 2 01c2f5eabdc4 000000000000 000000000000 (no-changeset !)
0 2 b789fdd96dc2 000000000000 000000000000 (changeset !) 0 2 b80de5d13875 000000000000 000000000000 (changeset !)
1 8 b004912a8510 000000000000 000000000000 1 8 b004912a8510 000000000000 000000000000
2 22 4a067cf8965d 000000000000 000000000000 (no-changeset !) 2 22 c72365ee036f 000000000000 000000000000 (no-changeset !)
2 22 fe6f8b4f507f 000000000000 000000000000 (changeset !) 2 25 68d5bca9df05 b80de5d13875 000000000000 (changeset !)
Log output should not include a merge commit as it did not happen Log output should not include a merge commit as it did not happen
$ hg log -Gfr 'desc("mBDm-0")' d $ hg log -Gfr 'desc("mBDm-0")' d
o 8 d-2 re-add d o 8 d-2 re-add d
| |
~ ~
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
#if no-changeset #if no-changeset
$ hg manifest --debug --rev 'desc("mAEm-0")' | grep '644 f' $ hg manifest --debug --rev 'desc("mAEm-0")' | grep '644 f'
c39c6083dad048d5138618a46f123e2f397f4f18 644 f eb806e34ef6be4c264effd5933d31004ad15a793 644 f
$ hg manifest --debug --rev 'desc("mEAm-0")' | grep '644 f' $ hg manifest --debug --rev 'desc("mEAm-0")' | grep '644 f'
a9a8bc3860c9d8fa5f2f7e6ea8d40498322737fd 644 f eb806e34ef6be4c264effd5933d31004ad15a793 644 f
$ hg manifest --debug --rev 'desc("a-2")' | grep '644 f' $ hg manifest --debug --rev 'desc("a-2")' | grep '644 f'
263ea25e220aaeb7b9bac551c702037849aa75e8 644 f 0dd616bc7ab1a111921d95d76f69cda5c2ac539c 644 f
$ hg manifest --debug --rev 'desc("e-2")' | grep '644 f' $ hg manifest --debug --rev 'desc("e-2")' | grep '644 f'
71b9b7e73d973572ade6dd765477fcee6890e8b1 644 f 6da5a2eecb9c833f830b67a4972366d49a9a142c 644 f
$ hg debugindex f $ hg debugindex f
rev linkrev nodeid p1 p2 rev linkrev nodeid p1 p2
0 4 263ea25e220a 000000000000 000000000000 0 4 0dd616bc7ab1 000000000000 000000000000
1 10 71b9b7e73d97 000000000000 000000000000 1 10 6da5a2eecb9c 000000000000 000000000000
2 19 c39c6083dad0 263ea25e220a 71b9b7e73d97 2 19 eb806e34ef6b 0dd616bc7ab1 6da5a2eecb9c
3 20 a9a8bc3860c9 71b9b7e73d97 263ea25e220a
#else #else
$ hg manifest --debug --rev 'desc("mAEm-0")' | grep '644 f' $ hg manifest --debug --rev 'desc("mAEm-0")' | grep '644 f'
498e8799f49f9da1ca06bb2d6d4accf165c5b572 644 f b80de5d138758541c5f05265ad144ab9fa86d1db 644 f
$ hg manifest --debug --rev 'desc("mEAm-0")' | grep '644 f' $ hg manifest --debug --rev 'desc("mEAm-0")' | grep '644 f'
c5b506a7118667a38a9c9348a1f63b679e382f57 644 f b80de5d138758541c5f05265ad144ab9fa86d1db 644 f
$ hg manifest --debug --rev 'desc("a-2")' | grep '644 f' $ hg manifest --debug --rev 'desc("a-2")' | grep '644 f'
b789fdd96dc2f3bd229c1dd8eedf0fc60e2b68e3 644 f b80de5d138758541c5f05265ad144ab9fa86d1db 644 f
$ hg manifest --debug --rev 'desc("e-2")' | grep '644 f' $ hg manifest --debug --rev 'desc("e-2")' | grep '644 f'
1e88685f5ddec574a34c70af492f95b6debc8741 644 f b80de5d138758541c5f05265ad144ab9fa86d1db 644 f
$ hg debugindex f $ hg debugindex f
rev linkrev nodeid p1 p2 rev linkrev nodeid p1 p2
0 4 b789fdd96dc2 000000000000 000000000000 0 4 b80de5d13875 000000000000 000000000000
1 10 1e88685f5dde 000000000000 000000000000
2 19 498e8799f49f b789fdd96dc2 1e88685f5dde
3 20 c5b506a71186 1e88685f5dde b789fdd96dc2
#endif #endif
# Here the filelog based implementation is not looking at the rename # Here the filelog based implementation is not looking at the rename
# information (because the file exist on both side). However the changelog # information (because the file exist on both side). However the changelog
# based on works fine. We have different output. # based on works fine. We have different output.
$ hg status --copies --rev 'desc("a-2")' --rev 'desc("mAEm-0")' $ hg status --copies --rev 'desc("a-2")' --rev 'desc("mAEm-0")'
M f M f (no-changeset !)
b (no-filelog !) b (no-filelog no-changeset !)
R b R b
$ hg status --copies --rev 'desc("a-2")' --rev 'desc("mEAm-0")' $ hg status --copies --rev 'desc("a-2")' --rev 'desc("mEAm-0")'
M f M f (no-changeset !)
b (no-filelog !) b (no-filelog no-changeset !)
R b R b
$ hg status --copies --rev 'desc("e-2")' --rev 'desc("mAEm-0")' $ hg status --copies --rev 'desc("e-2")' --rev 'desc("mAEm-0")'
M f M f (no-changeset !)
d (no-filelog !) d (no-filelog no-changeset !)
R d R d
$ hg status --copies --rev 'desc("e-2")' --rev 'desc("mEAm-0")' $ hg status --copies --rev 'desc("e-2")' --rev 'desc("mEAm-0")'
M f M f (no-changeset !)
d (no-filelog !) d (no-filelog no-changeset !)
R d R d
$ hg status --copies --rev 'desc("i-2")' --rev 'desc("a-2")' $ hg status --copies --rev 'desc("i-2")' --rev 'desc("a-2")'
A f A f
d d
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 h R h
$ hg status --copies --rev 'desc("i-0")' --rev 'desc("mFBm-0")' $ hg status --copies --rev 'desc("i-0")' --rev 'desc("mFBm-0")'
M b M b
A d A d
h h
R a R a
R h R h
$ hg status --copies --rev 'desc("b-1")' --rev 'desc("mBFm-0")' $ hg status --copies --rev 'desc("b-1")' --rev 'desc("mBFm-0")'
M d M d (no-changeset !)
h (no-filelog !) h (no-filelog no-changeset !)
R h R h
$ hg status --copies --rev 'desc("f-2")' --rev 'desc("mBFm-0")' $ hg status --copies --rev 'desc("f-2")' --rev 'desc("mBFm-0")'
M b M b
$ hg status --copies --rev 'desc("f-1")' --rev 'desc("mBFm-0")' $ hg status --copies --rev 'desc("f-1")' --rev 'desc("mBFm-0")'
M b M b
M d M d (no-changeset !)
i (no-filelog !) i (no-filelog no-changeset !)
R i R i
$ hg status --copies --rev 'desc("b-1")' --rev 'desc("mFBm-0")' $ hg status --copies --rev 'desc("b-1")' --rev 'desc("mFBm-0")'
M d M d (no-changeset !)
h (no-filelog !) h (no-filelog no-changeset !)
R h R h
$ hg status --copies --rev 'desc("f-2")' --rev 'desc("mFBm-0")' $ hg status --copies --rev 'desc("f-2")' --rev 'desc("mFBm-0")'
M b M b
$ hg status --copies --rev 'desc("f-1")' --rev 'desc("mFBm-0")' $ hg status --copies --rev 'desc("f-1")' --rev 'desc("mFBm-0")'
M b M b
M d M d (no-changeset !)
i (no-filelog !) i (no-filelog no-changeset !)
R i R i
#if no-changeset #if no-changeset
$ hg log -Gfr 'desc("mBFm-0")' d $ hg log -Gfr 'desc("mBFm-0")' d
o 22 f-2: rename i -> d o 22 f-2: rename i -> d
| |
o 21 f-1: rename h -> i o 21 f-1: rename h -> i
: :
o 0 i-0 initial commit: a b h o 0 i-0 initial commit: a b h
#else #else
BROKEN: `hg log --follow <file>` relies on filelog metadata to work BROKEN: `hg log --follow <file>` relies on filelog metadata to work
$ hg log -Gfr 'desc("mBFm-0")' d $ hg log -Gfr 'desc("mBFm-0")' d
o 22 f-2: rename i -> d o 2 i-2: c -move-> d
| |
~ ~
#endif #endif
#if no-changeset #if no-changeset
$ hg log -Gfr 'desc("mFBm-0")' d $ hg log -Gfr 'desc("mFBm-0")' d
o 22 f-2: rename i -> d o 22 f-2: rename i -> d
| |
o 21 f-1: rename h -> i o 21 f-1: rename h -> i
: :
o 0 i-0 initial commit: a b h o 0 i-0 initial commit: a b h
#else #else
BROKEN: `hg log --follow <file>` relies on filelog metadata to work BROKEN: `hg log --follow <file>` relies on filelog metadata to work
$ hg log -Gfr 'desc("mFBm-0")' d $ hg log -Gfr 'desc("mFBm-0")' d
o 22 f-2: rename i -> d o 2 i-2: c -move-> d
| |
~ ~
#endif #endif
Merge: Merge:
- one with change to a file - one with change to a file
- one deleting and recreating the file - one deleting and recreating the file
| |
| The current code arbitrarily pick one side depending the ordering of the merged hash: | The current code arbitrarily pick one side depending the ordering of the merged hash:
In this case, the file hash from "f-2" is lower, so it will be `p1` of the resulting filenode its copy tracing information will win (and trace back to "h"): In this case, the file hash from "f-2" is lower, so it will be `p1` of the resulting filenode its copy tracing information will win (and trace back to "h"):
Details on this hash ordering pick: Details on this hash ordering pick:
$ hg manifest --debug 'desc("g-1")' | egrep 'd$' $ hg manifest --debug 'desc("g-1")' | egrep 'd$'
f2b277c39e0d2bbac99d8aae075c0d8b5304d266 644 d (no-changeset !) 7bded9d9da1f7bf9bf7cbfb24fe1e6ccf68ec440 644 d (no-changeset !)
4ff57b4e8dceedb487e70e6965ea188a7c042cca 644 d (changeset !) 68d5bca9df0577b6bc2ea30ca724e13ead60da81 644 d (changeset !)
$ hg status --copies --rev 'desc("i-0")' --rev 'desc("g-1")' d $ hg status --copies --rev 'desc("i-0")' --rev 'desc("g-1")' d
A d A d
a (no-changeset no-compatibility !) a (no-changeset no-compatibility !)
$ hg manifest --debug 'desc("f-2")' | egrep 'd$' $ hg manifest --debug 'desc("f-2")' | egrep 'd$'
4a067cf8965d1bfff130057ade26b44f580231be 644 d (no-changeset !) c72365ee036fca4fb27fd745459bfb6ea1ac6993 644 d (no-changeset !)
fe6f8b4f507fe3eb524c527192a84920a4288dac 644 d (changeset !) b80de5d138758541c5f05265ad144ab9fa86d1db 644 d (changeset !)
$ hg status --copies --rev 'desc("i-0")' --rev 'desc("f-2")' d $ hg status --copies --rev 'desc("i-0")' --rev 'desc("f-2")' d
A d A d
h (no-changeset no-compatibility !) h (no-changeset no-compatibility !)
Copy tracing data on the resulting merge: Copy tracing data on the resulting merge:
$ hg status --copies --rev 'desc("i-0")' --rev 'desc("mFGm-0")' $ hg status --copies --rev 'desc("i-0")' --rev 'desc("mFGm-0")'
A d A d
h h (no-filelog !)
a (filelog !)
R a R a
R h R h
$ hg status --copies --rev 'desc("i-0")' --rev 'desc("mGFm-0")' $ hg status --copies --rev 'desc("i-0")' --rev 'desc("mGFm-0")'
A d A d
a (no-filelog !) a (no-changeset !)
h (filelog !) h (changeset !)
R a R a
R h R h
$ hg status --copies --rev 'desc("f-2")' --rev 'desc("mFGm-0")' $ hg status --copies --rev 'desc("f-2")' --rev 'desc("mFGm-0")'
M d M d
$ hg status --copies --rev 'desc("f-2")' --rev 'desc("mGFm-0")' $ hg status --copies --rev 'desc("f-2")' --rev 'desc("mGFm-0")'
M d M d
$ hg status --copies --rev 'desc("f-1")' --rev 'desc("mFGm-0")' $ hg status --copies --rev 'desc("f-1")' --rev 'desc("mFGm-0")'
M d M d
i (no-filelog !) i (no-filelog !)
R i R i
$ hg status --copies --rev 'desc("f-1")' --rev 'desc("mGFm-0")' $ hg status --copies --rev 'desc("f-1")' --rev 'desc("mGFm-0")'
M d M d
i (no-filelog !) i (no-filelog !)
R i R i
$ hg status --copies --rev 'desc("g-1")' --rev 'desc("mFGm-0")' $ hg status --copies --rev 'desc("g-1")' --rev 'desc("mFGm-0")'
M d M d (no-changeset !)
h (no-filelog !) h (no-filelog no-changeset !)
R h R h
$ hg status --copies --rev 'desc("g-1")' --rev 'desc("mGFm-0")' $ hg status --copies --rev 'desc("g-1")' --rev 'desc("mGFm-0")'
M d M d (no-changeset !)
h (no-filelog !) h (no-filelog no-changeset !)
R h R h
#if no-changeset #if no-changeset
$ hg log -Gfr 'desc("mFGm-0")' d $ hg log -Gfr 'desc("mFGm-0")' d
o 28 mFGm-0 simple merge - one way o 28 mFGm-0 simple merge - one way
|\ |\
| o 25 g-1: update d | o 25 g-1: update d
| | | |
o | 22 f-2: rename i -> d o | 22 f-2: rename i -> d
| | | |
o | 21 f-1: rename h -> i o | 21 f-1: rename h -> i
|/ |/
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
#else #else
BROKEN: `hg log --follow <file>` relies on filelog metadata to work BROKEN: `hg log --follow <file>` relies on filelog metadata to work
$ hg log -Gfr 'desc("mFGm-0")' d $ hg log -Gfr 'desc("mFGm-0")' d
o 28 mFGm-0 simple merge - one way o 25 g-1: update d
|\ |
| o 25 g-1: update d
| |
o | 22 f-2: rename i -> d
|/
o 2 i-2: c -move-> d o 2 i-2: c -move-> d
| |
~ ~
#endif #endif
#if no-changeset #if no-changeset
$ hg log -Gfr 'desc("mGFm-0")' d $ hg log -Gfr 'desc("mGFm-0")' d
o 29 mGFm-0 simple merge - the other way o 29 mGFm-0 simple merge - the other way
|\ |\
| o 25 g-1: update d | o 25 g-1: update d
| | | |
o | 22 f-2: rename i -> d o | 22 f-2: rename i -> d
| | | |
o | 21 f-1: rename h -> i o | 21 f-1: rename h -> i
|/ |/
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
#else #else
BROKEN: `hg log --follow <file>` relies on filelog metadata to work BROKEN: `hg log --follow <file>` relies on filelog metadata to work
$ hg log -Gfr 'desc("mGFm-0")' d $ hg log -Gfr 'desc("mGFm-0")' d
o 29 mGFm-0 simple merge - the other way o 25 g-1: update d
|\ |
| o 25 g-1: update d
| |
o | 22 f-2: rename i -> d
|/
o 2 i-2: c -move-> d o 2 i-2: c -move-> d
| |
~ ~
#endif #endif
Comparing with merging with a deletion (and keeping the file) Comparing with merging with a deletion (and keeping the file)
------------------------------------------------------------- -------------------------------------------------------------