Thanks, Ben! Responses inline. If you have the time, I'd be curious to
hear about why my expectations didn't match what darcs actually did.

> > What I'd like to do is create a repository R1 with patches A and B,
> > and then look at the patches that result if A and B get
> > force-commuted.
> >
> > E.g. if I could pull just patch B and not A to a new repository, I
> > think that would do the trick, but of course darcs pull won't let me
> > do that because B depends on A.
> The main question here is: What do you expect the result of such a
> force-commute would be?
> Let us take a very simple example:
> A = addfile ./foo
> B = hunk ./foo 1 [] ["some text"]
> where the hunk notation is simplified but hopefully understandable (the
> hunk here removes no lines and adds the line "some text").
> Suppose you had a 'darcs force-commute' command, and you force-commuted
> A;B to B';A'. What would you expect the B' then A' to be?

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.

However, that doesn't seem to be what happened (see below).

Even if that were correct, it still doesn't leave me with a complete
picture of what darcs actually does, so I wanted to experiment.

> > Question 1: Is there a simple way to make darcs do this?
> Not exactly simple, but it is possible:
> darcs clone . ../saved
> darcs rebase suspend # select B and A
> darcs rebase obliterate # select A
> darcs rebase unsuspend # select B
> darcs pull ../saved # select A
> You should expect to get conflicts first when you unsuspend B (after
> obliterating A) and then also when you re-pull A from the clone. You
> will probably want to amend the conflict resolution into the conflicted
> patch.

Thanks, that seems to have worked. (I only got the first conflict, not
the second.) But now I'm confused.

Based on, for example, the "Forced commutation" section of
, I expected B' to add the file "foo", and A' to add "some text" (so,
B' has the effect of A and A' has the effect of B).

Instead of that, I get this:

(a) If I follow your advice and amend the conflict resolution into B'
before pulling, then (the amended) B' has the effect of AB, and A' has
no effect.

(b) If I run "darcs revert" instead of amending the conflict
resolution into B', then B' has the effect of A and A' still has no

Confusingly, darcs offers to pull B from ../saved --- I thought darcs
should consider it to already be present (as B').

I also noticed that if I run the swap a second time, I don't exactly
get A and B back. (In the (a) case, I get patches with the same
effects, but the new B starts with "duplicate"). I thought commutation
was always supposed to be symmetric. Does that not apply when
conflictors are involved?

> Cheers
> Ben


[0] "Understanding darcs" on Wikibooks, "A formalization of Darcs
patch theory using inverse semigroups", and some of Camp's
darcs-users mailing list

Reply via email to