[darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

[James Cook]

> Converting existing repos to darcs-3 is unfortunately one of the things
> we havent't done yet. I have implemented a number of conversion schemes
> but they all fail in some situations. There are two hard problems to
> solve here:
>
> (1) What to do about so called "Duplicates" in the darcs-2 format. These
> have no equivalent in the darcs-3 format (in darcs-3 duplicate prim
> patches conflict).
>
> (2) How to ensure separately converted branches of a project remain
> interoperable. The existing 'convert darcs-2' command gives up on this
> and simply assigns new identities for all patches. This means you cän
> convert at most one branch and have to throw away all others. (Or first
> merge them all into a single repo, but that typically hits the dreaded
> eponential behavior in the darcs-1 format, so in practice normally
> doesn't work.) I always found this to be an extremely poor user
> experience! It is one of the reasons many people never converted their
> repos to the darcs-2 format.

As an attempt to solve problem (2) ignoring problem (1), what would
happen if you used the entire darcs-2 patch theory, including
conflictors, as the primitive patch theory for darcs-3? The idea being
that you avoid creating any new darcs-2 conflictors going forward, but
if you do encounter them, they're just a legacy type of primitive
patch. Or does the existence of darcs-2 style conflictors make the
patch theory unsuitable?

As an even more desparate attempt to solve (1), what if you said the
primitive patch theory is a disjoint union of (a) "old-style" darcs-2
patches and (b) "new-style" darcs-3 primitive patches, and type (a)
and (b) patches never commute? In practice you'd get awful conflicts
if you tried to interleave darcs-2 and darcs-3 work, but in theory
could that conversion be lossless? (Maybe old-style and new-style
patches could sometimes commute. I'm trying to treat them as black
boxes, making no assumptions.)

James