Finally! This took me *much* longer to finish than I expected.
4 patches for repository https://darcs.net/screened:
patch c4a890da8b461c287e924be82d1dea26eeac35a4
Author: Ben Franksen <ben.franksen@online.de>
Date: Fri Jun 21 20:23:17 CEST 2024
* resolve issue2727: conflict resolution should be invariant under reordering
This is almost, though not quite, a re-write of 'resolveConflicts' for Named
patches. There were many things wrong with the old version. For instance,
reliably determining the patches that a Named patch conflicts with is more
involved than just a call to findConflicting. Also, lessons learned from the
latest bug fixes to resolveConflicts for RepoPatchV3 have been applied here
as well. Particularly, the question of which conflicts have been resolved at
the Named patch layer via explicit dependencies can and should be answered
for direct conflicts between two patches. Transitive conflicts do /not/ play
any role here, they are only important to finally generate the conflicting
alternatives, and that is (as before) done at the RepoPatch level. For
clarity, I decided to split the algorithm into two passes, one which gathers
the necessary information (conflicts, dependencies), and another one to
separate patch contents into resolved (by explicit dependencies) and
unresolved (by same). This makes it more verbose overall, and perhaps
slightly less efficient. But it should be clearer now what is happening and
why. It is also much easier to debug in this form, since we can trace
intermediate results to locate where things start to go wrong.
patch 335821a41013031fa92037b583a91759cc8148bf
Author: Ben Franksen <ben.franksen@online.de>
Date: Fri Jun 21 21:02:31 CEST 2024
* a few local renamings in Darcs.Patch.Named for better clarity
patch 9277a3c136a7cfb4bf31acbaca68df36a7846db2
Author: Ben Franksen <ben.franksen@online.de>
Date: Fri Jun 21 20:36:24 CEST 2024
* rollback "disable propResolutionsOrderIndependent for Named patches"
The property no longer fails for Named patches.
patch 5ef23cf7405e66b030efaa7fc773f1562b9f0334
Author: Ben Franksen <ben.franksen@online.de>
Date: Fri Jun 21 20:38:16 CEST 2024
* a number of new regression tests for issue2727
These all came up during my attempts at fixing issue2727 and are based on
failing QC test cases, which I manually reconstructed. Some of them (notably
4, 5, 8, and 11) pass even before applying the final fix for issue2727 (but
after the fixes for RepoPatchV3); they represent bugs I introduced on my way
toward the final solution. I decided to include them anyway, in case we ever
have to touch that code again.
Attachments
|