[darcs-users] questions on patch theory

[Mirian Crzig Lennox]

droundy at abridgegame.org (David Roundy) writes:
> > 
> > So, in your illustration above, I would say that A and A' are separate
> > and distinct patches.  However, in their respective contexts, they
> > describe the same change (or semantic change, or metapatch, etc.).
> > 
> > What do you think?
> 
> Hmmmm.  That's an appealing idea.  I hadn't been able to figure out a
> terminology I was really happy with for the distinction between a patch and
> its representation.  Now that I think about it, calling the unchanging
> thing a change and its representation a patch is pretty intuitive.
> "Patches A and A' represent the same change" is a statement that is pretty
> clear, and would only become more clear with a good definition of what a
> change is and what a patch is...  I think I'll make this change whenever I
> get around to revising my theory of patches appendix.  Thanks for the
> suggestion!  :)

I'm glad you like it.  It also works out nicely since there's already
a "darcs changes" command.

> Well, I think it becomes redundant if you simply modify it so that the
> precedence relationship becomes a relationship between a patch and a
> change.  A patch is preceded by every change that is in its context.  If
> you like, you could defined it in terms of patches by saying that a patch
> is preceded by every patch that represent a change in its context, and
> whose context is a subset of the first patch's context.  I think with this
> second (and somewhat more awkward) definition, your transitivity
> relationships and so on would be true.

All right.  Just as a reality check, one of the assumptions I'm making
is that, for any existing composition of patches AB, exactly one of
the following is true:

        (1)  A is dependent on B
        (2)  AB <-> BA    (i.e. A and B represent orthogonal changes)
        (3)  AB <-> BA'   (changing context modifies A)
        (4)  AB <-> B'A   (changing context modifies B)

In particular, it's never the case that commutation requires both A
and B to change (AB <-> B'A').  (At least, I can't think of a reason
why it should; can you?)

For want of a better word, I've been calling this effect "influence"
(or the lack thereof).  In (3), B influences A because A is modified
leaving B's context.  In (4), A influences B because B is modified
entering A's context.  In (2), neither change has influence over the
other.  And of course, in (1), B exerts maximal influence over A (such
that A is indeed stuck in B's context).

The useful feature of influence is that it is defined entirely on
changes, rather than patches, and I believe it also obeys
transitivity.  Precedence is essentially influence plus context: a
patch is preceded by all changes in its context which influence it.

cheers,
--Mirian