> 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.
I was wondering if global uniqueness could be solved by borrowing from Pijul. If you include some metadata as part of the repository state (e.g. the identity of the hunk responsible for every line of every text file) then I think you could make it so that a primitive patch's representation doesn't change when it's commuted. I suspect pretty much any primitive patch theory could be adapted to work this way. (Note I'm not claiming this will make everything actually commute like in Pijul.) Besides giving unique names, another nice thing about this is that you shouldn't need to implement n^2 different patch commuting functions for n types of primitive patch. (I don't know if darcs actually needs to do this; I'm just assuming.) If you have access to the repo state, you can tell if two patches commute just by trying to apply them in the opposite order and seeing if they complain. In theory, you could even allow plugins that implement new patch types, with the basic principle that patches communicate with each other through modifications to the repo metadata. A slightly less radical version of this would be to keep the current primitive patch representation, but use this idea when generating the patch names. E.g. a hunk's name is a hash involving the identities of the hunks responsible for the lines it deletes. You'd still need to keep some metadata around to be able to do that, though. James _______________________________________________ darcs-users mailing list firstname.lastname@example.org https://lists.osuosl.org/mailman/listinfo/darcs-users