I just found this patch of yours that was never screened while cleaning up
the rebase state in one of my clones. I have amended the patch to avoid
warnings and to avoid running the test when the patch type does not allow
coalescing. I think this should go into 2.16 as it clarifies what works with
the new rebase implementation. It is of course also valuable to avoid
regressions.

1 patch for repository http://darcs.net/screened:

patch ba4ca2fb7b6969a24356d36bc4551b43cf7b7e95
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Thu May 14 21:29:32 CEST 2020
  * test for whether rebase suspend/unsuspend introduces conflicts

Attachments

• patch-preview.txt
• test-for-whether-rebase-suspend_unsuspend-introduces-conflicts.dpatch
• unnamed

Screening

I check it cleanly builds with all supported compiler versions.
Test succeeds.

Are you sure this passes? I just tried it with reviewed and it failed for v1 
and v2 with the standard count (100). From what I recall of my previous
experiments, it would also fail with v3 with a larger test count.

> Are you sure this passes? I just tried it with reviewed and it failed for v1 
> and v2 with the standard count (100). From what I recall of my previous
> experiments, it would also fail with v3 with a larger test count.

I did run the test and it succeeded for me. But with larger test counts
it fails for me, too.

I have obliterated the patch from branch-2.16, reviewed, and screened
and marked the patch as in-discussion.

Sorry about this.

I don't think we have a concept of failing unit tests, but if we did it 
would make sense to include this as one.

I think it _might_ also pass for starting sequences of length 2. Looking
again at this test was one of the things I was vaguely planning on doing as
part of my promise to try to characterise what works and doesn't with the
new rebase implementation.

A WIP bundle to record progress on getting this test ready.

Some notes:

1) I had to refactor a bit to deal with the fact that
addToEditsToSuspended became in IO after the recent fixes
to change the identity of patches on suspend. The first
two patches to generalise that over MonadRandom could
probably be submitted now.

2) The test as-is does mostly need a high repeat count to
fail, I must have got lucky/unlucky when I broke it with
a count of 100 at one point.

3) If we cut down the maximum sequence to size 2, then it
passes for V1 and V3, but fails for V2. I guess this is
duplicate-induced but I haven't checked yet.

4) The current generation approach with bSized doesn't
work well with limiting sequence sizes for one test.
Not sure what the cleanest solution to that is.


4 patches for repository darcs-unstable@darcs.net:screened:

patch 60561a1865862a6f82251ae06bfa4cc7dc409136
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sun Aug 23 09:27:09 BST 2020
  * remove unused export of Darcs.Patch.Info.addJunk

patch 22f1742ed9ddc202940ab0ed59dc2e1d6941c403
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sun Aug 23 13:41:57 BST 2020
  * Generalise D.P.I.replaceJunk and callers to MonadRandom
  
  The warning about existing "Ignore-this" lines, which also
  constraints types to IO, is only wanted for newly recorded
  or amended patch information being created via 'patchinfo',
  not for ones where we are only modifying an existing patch
  with 'replaceJunk'. A new 'addJunkWarn' function is used to
  make this distinction.

patch a9571a494f551120bd86fefb304c35081821cf18
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sun Aug 23 14:17:57 BST 2020
  * test for whether rebase suspend/unsuspend introduces conflicts

patch d24bf74cc0587529880e05e9f495e04b6f430f54
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sun Aug 23 20:42:43 BST 2020
  * WIP: limiting the test to sequences of length 2
  It also needs changes to the generator to avoid it running
  out of cases.

Attachments

• patch-preview.txt
• remove-unused-export-of-darcs_patch_info_addjunk.dpatch
• unnamed