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 identities). 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 improvements. Cheers Ben _______________________________________________ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
