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

Ben Franksen ben.franksen at online.de
Mon Jun 29 10:01:39 UTC 2020

Am 29.06.20 um 03:54 schrieb James Cook:
> I'm glad to hear about darcs-3. I was worried work on implementing
> Camp had stopped completely.

Yes, I am quite happy about that, too. It means we finally have an
implementation of a patch theory that satisfies all required patch laws.
We have upgraded our QuickCheck test case generator so it now generates
all possible sorts of repositories and we have verified that the darcs-3
format indeed upholds all properties, even if we seriously crank up the
number of generated tests.

> Is testing helpful at this point?

Testing always helps.

If you have a machine with lots of cores and memory, try running the
test suite with "-t RepoPatchV3 -q 100000 -j <number of cores>". This
can take a lot of time to complete, depending on the arguemnt for the
-q option.

> I could try cloning and converting my repos to darcs-3.

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.

My failed attempts to come up with a complete solution for both (1) and
(2) convinced me that we will have to find some sort of compromise here.

In particular, I think we won't be able to uphold (2) under all
circumstances. This led me to investigate how we could at least make
sure that we can /detect/ when separately converted repos are
incompatible. The error message should be good enough that users can
make an informed choice about how to work around the problem: either
discard one of the branches, or discard (i.e. obliterate) only some
patches, or else try to re-record/amend them (which gives them new

This in turn led me to the more general question of how to detect
inconsistencies when exchanging patches between repos. The problem here
is that darcs currently relies on global uniqueness properties that are
quite easy to invalidate (e.g. by manually editing patches, and as
hinted above also when we independently convert branches of a repo).
Specifically, we rely on the following global property: if two patches
have the same name/identity, then (a) they can always be commuted to a
common context and (b) they are equal (content-wise) after commuting
them to any such common context. (The context of a patch is defined as
the set of patches preceding it.) Effectively this property means that
patches with the same name/identity are really just commuted/merged
versions of one and the same original patch.

I have an (efficient) algorithm in mind that validates these assumptions
whenever we exchange patches between repos. Implementing this requires a
pretty deep refactor though.

The upshot is that we won't get conversion to darcs-3 until we can
reliably detect inconsistencies between repos.  And before I can come
around to fully concentrate on implementing that, we have to get out
release 2.16 because our head is now many hundreds of patches beyond the
last release (2.14.4) and there have been lots of bug fixes and other


More information about the darcs-users mailing list