[Request] [+++ ] D8652: tests: test more cases where a file got replaced by a copy

[martinvonz (Martin von Zweigbergk)]

martinvonz created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  This adds a test where a file is modified on one branch and is renamed
  onto another file in another branch. That should ideally be
  automatically resolved (by propagating the modification to the rename
  destination). Alternatively, it could be considered a modify/delete
  conflict. It should at least not be automatically resolved by ignoring
  the modification. However, that is what actually happens with the
  changeset-centric algorithm since I broke it in b4057d001760 <https://phab.mercurial-scm.org/rHGb4057d0017601357a59a18f2996719302ae51765> (merge:
  when rename was made on both sides, use ancestor as merge base,
  2020-01-22). Before that commit, it resulted in a modify/delete
  conflict. The filelog-centric algorithm was broken already before that
  commit.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8652

AFFECTED FILES
  tests/test-copies.t

CHANGE DETAILS

diff --git a/tests/test-copies.t b/tests/test-copies.t
--- a/tests/test-copies.t
+++ b/tests/test-copies.t
@@ -462,6 +462,73 @@
   $ 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]
+BROKEN: should be "modified"
+  $ cat y
+  original
+#else
+  $ hg merge 2
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  (branch merge, don't forget to commit)
+BROKEN: should be "modified"
+  $ cat y
+  original
+#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
+  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  (branch merge, don't forget to commit)
+BROKEN: should be "modified"
+  $ cat y
+  original
+#endif
 
 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



To: martinvonz, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercurial-scm.org/pipermail/mercurial-patches/attachments/20200623/1d162817/attachment.html>