[darcs-users] Anti-files that annihilate with files when they're created

David Roundy droundy at abridgegame.org
Wed May 19 11:38:57 UTC 2004

On Tue, May 18, 2004 at 08:13:11PM +0000, Bennett Todd wrote:
> and other anti-patches. I've seen the idea mentioned more than once, in
> the docs and in the email archives, of anti-files and other anti-patches
> that allow otherwise dependent patches to commute.  Patch A creates a
> file "foo", patch B deletes file "foo", to make apply B then apply A
> work, applying B needs to leave an anti-file "foo" to annihilate with foo
> if and when A comes along later to create the file.
> It just hit me that this sounds like a collection of pending
> patches. When applying B before A, not that "delete foo" doesn't apply
> yet, and put it in pending. When applying A later, note the pending patch
> and have "create A" succeed without doing anything.
> Would this (and its obvious generalization to other sorts of patches) be
> a useful concept in darcs?

Yes, this sounds basically like an idea I want to try out after darcs 1.0
is released, which is motivated as a different way of thinking about
conflicts.  The idea is to allow any commutation, but have any commutations
that currently would fail produce "conflicted" patches.  This new
commutation operator (that never fails) would mean that the "merge theorem"
would always apply, which would be a very handy feature.  The catch is that
all the algorithms would have to modified to deal with this--or I'd have to
give this "fancy non-failing commute" a different name, force_commute or

Anyhow, so if A is followed by B and they don't commute, then 

force_commute A B == C(B,A) C'(A,B)

where C and C' are to be defined... (C standing for "conflict").  The
commutation behavior of C and C' should be well-defined already, and just
needs to be worked out.  What C(B,A) actually does is arbitrary, but could
probably be determined by the constraint of backwards-compatibility for
mergers--it'd be nice to not have to fossilize old merge conflicts due to a
change in merge behavior.

In case I lost you, the idea here is to encode the "pending" behavior of B
(which perhaps removes the file that A adds) in C'(A,B)--which is somewhat
different perhaps from what you were thinking, which was perhaps in
recording the pending "B" change somewhere, to be triggered when A is
reached.  I.e. I think you may have been imagining something like

force_commute A B == C(B,A) A

which would be trickier.

Alas, darcs seems to be taking forever to stabilize, and I've now got I
don't know how many features I'd like to add after 1.0 is released.
David Roundy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20040519/02bac707/attachment.pgp 

More information about the darcs-users mailing list