Re: Make darcs force-commute patches from CLI, to learn about darcs?

> 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