This beefs up the existing rebase-move test to check that the
final repository contents are as expected. If we amend a
patch in the repository to rename a file, we expect that
rename to be propagated through the rebase.

1 patch for repository darcs-unstable@darcs.net:screened:

patch e90653c170ff637a03ab58e062a003e643359d19
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sat May 30 17:00:46 BST 2020
  * tests/rebase-move; validate the final repository contents

Attachments

• patch-preview.txt
• tests_rebase_move_-validate-the-final-repository-contents.dpatch
• unnamed

This test fails with the rebase with conflicted fixups because we now
get a conflict on unsuspend.

To see more clearly what goes on, I changed the test so that the addfile
is recorded separately as a first step. Then the test succeeds with
darcs-2 because merging the amended version of the patch produces a
Duplicate fixup which isn't reported as a conflict. For darcs-1 and
darcs-3 you get a conflict instead. I don't think this is unreasonable
or surprising behavior, though the fact that this works with a prim
based rebase is certainly nice.

I discussed this in a bit more detail here:
https://lists.osuosl.org/pipermail/darcs-devel/2020-May/021167.html

With conflicted fixups we don't get an actual conflict on unsuspend, because
the test would have failed originally if we did. But we do get what I think
is a wrong result.

Sorry, yes, you get a conflict only if the test is changed to record the
addfile separately. I see now that with the original test we get
behavior that is indeed... strange. Interesting.