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

> > I've been reading about patch theory [0]. I *thought* what's supposed
> > to happen is this:
> >
> > * The effect of B' is the same as the effect of A. (i.e. create the file)
> > * The effect of A' is the same as the effect of B. (i.e. add "some text")
> > * Therefore, B'A' does the same thing as AB.
> > * B' and A' include some information about the conflict, in addition
> > to their effects described above. (They are "conflictor" patches.)
> > * If I commute B' and A' again, I get back AB, since <-> is a
> > symmetric relation.
>
> I understand. However, there is no patch theory I am aware of that is
> able to make this work, except those where *any* two patches commute, so
> there are no dependencies and patches never conflict.

Thank you. I've learned a lot from your reply.

I have an idea for a patch theory that would satisfy these properties,
and may have other advantages and might even be backward-compatible with
darcs. I am not confident that it works, but I would love to have some
feedback, if someone finds the time to read it. Is this list a good
place to post something like that?

> As I said in the beginning, there is no force-commute command in darcs
> because that would be unsound. By definition, if B depends on A this
> means A;B does /not/ commute. In the theory, one starts with primitive
> patches for which there is no total merge operation, only a partial
> clean-merge that may fail. If you have two independently recorded
> patches A and B in the same context (we write this as A\/B), then
> clean-merge succeeds iff A^;B commutes (where ^ means inversion). If
> clean-merge(A\/B) does not succeed, then A\/B are said to be in conflict.

Does darcs satisfy the property that if I merge two arbitrary
repositories R and S to produce a new repository M, then separate out
the patches again (i.e. pull just R's patches or just S's patches from
M to a fresh repo) then I get back R and S?

I hope the question makes sense. I can write a concrete sequence of
commands if it doesn't.

I had assumed this property was true because I thought force-commuting
satisfied the magical properties in my previous email. I hope it is
still true despite me being wrong about force-commuting.

> When we add conflictors, we extend the set/type of primitive patches to
> a larger set, such that now any two patches can be merged. However, we
> must require that this extension preserves commutation behavior. In
> particular, if A;B does not commute, then their embeddings in the larger
> set of patches must commute neither.

Ah, I had a different picture in mind. I thought that after adding in
conflictors, then technically you end up with a universe of patches
where everything commutes, but the patches end up looking ugly and
unintuitive if you commute things that aren't "supposed" to. I thought a
"force-commute" was simply a commute that wouldn't have been possible
before adding conflictors to your universe of patches. This is what I
hope my patch theory accomplishes.

James