> Another problem is that even supposing commutation does not change prim > patches, in darcs you still have conflictors. And conflictors > /definitely/ have to change representation when we commute them: the > merge-commute law obviously requires that.
Could the conflictors be re-computed? In more detail: Suppose we've managed to make it so primitive patches never change representation. I tell you I built my repo by pulling the primitive patches A, B and C in some arbitrary order, changing them into conflictors when necessary. (I might also have done some other operations, like adding and later obliterating patches, or commuting things.) I also tell you that the final order of patches in my repo is AB'C', where B' is either B itself or a conflictor keeping B's identity (and same for C'). Could there ever be more than one possible answer for what B' and C' end up being? If not, doesn't that mean that the identities of A, B and C are enough to verify we've got the same repo? I take your point, though, that maintaining metadata in the repository state, as required for all this, would be hard. > > 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. > > That may be possible, especially for a completely new project that is > designed around these notions from the start. Sorry to extend this tangent even further (if you keep responding to my emails, I'll likely keep sending them :-P), but I had another thought: you don't actually need to store the metadata with the repo state. You could instead put some metadata into the patches, and allow patches to modify each others' metadata when they try to commute. Well, at least I think it would work... let me know if you want details. This loses global uniqueness (since patch metadata changes when commuting), but might help (a) if you want to allow plugins but don't want to deal with metadata being part of the repo state, or (b) if you're trying to reason about a complicated primitive patch theory and want a way to avoid considering n^2 cases. (Based on your email, it sounds like (b) is not a practical concern, though.) James _______________________________________________ darcs-users mailing list firstname.lastname@example.org https://lists.osuosl.org/mailman/listinfo/darcs-users