1 patch for repository http://darcs.net/screened:
Author: Ben Franksen <firstname.lastname@example.org>
Date: Sat Dec 3 15:46:23 CET 2022
* optimize conflict resolution in tentativelyMergePatches_
Examining patches for conflicts and then generating the markup is complex
and scales poorly with the length of the sequence to be examined. So it
makes sense to always choose the shorter of the two merged sequences to
apply standardResolution on; the more so since in almost all cases occurring
in practice the length of at least one of the two sequences is pretty short.
However, this is only valid if the remote patches don't have unresolved
conflicts in the first place. Detecting this condition requires another
conflict resolution step, but one that is usually cheap because it can stop
at the first clean tag.
With this patch, pulling everything from a large repo (e.g. darcs screened)
into an empty repository, while still not nearly as fast as a clone,
completes in a reasonable time (and also doesn't run into darcs-2 commute
bugs). This could be further improved by optimizing the process of updating
the working tree which is a lot slower than updating pristine.
Looks fine. I haven't thought in detail about whether conflict
resolution is symmetric like this but it seems reasonable.
> + null $ conflictedPaths $ patchsetConflictResolutions $
Using "conflictedPaths" as the indicator of "are there any conflicts"
seems standard in other places in the code, but it does feel a bit
ugly. It doesn't seem intrinsic that a conflict has to be associated
with some path, though it's no doubt true right now, at least if
we ignore the already-broken setpref patches.