Re: questions on patch theory

droundy@xxxxxxxxxxxxxxx (David Roundy) writes:
> This brings up one other problem, which is that I have two different
> meanings for the term patch.  One is the logical change defined by the
> patch.  The other is the "representation" of the patch.  So in a commute
> 
> AB <-> B'A'
> 
> A' is the same patch as A (in the first sense), but its representation is
> different, because its representation is with respect to a context that is
> lacking B.  This second issue is more serious than the first, since in the
> first case the two definitions are equivalent, but certainly the
> representation of a patch mustn't be mistaken for the patch itself, and I
> suspect that at places I refer to the representation of a patch as a
> "patch."

Thank you for the clarification.  I suspect that much of my confusion
has arisen from an incomplete understanding of the distinction between
a patch and its representation.

Most of the time when you use the term "patch" in your theory of
patches, you do appear to mean the representation rather than the
logical change.  In fact, the only time when you appear to use "patch"
at all in the other sense is when justifying why commutation works.  I
imagine that a lot of people get tripped up by this; I certainly did.

In my opinion, it would be much more clear to have "patch" mean
exclusively the representation, and rely on the <-> operator to convey
the notion of semantic equality.  If necessary, coin a new term such
as "change", "logical change", or "semantic change" to mean "what the
patch represents".  Or perhaps, "metapatch", to coin an entirely new
word but keep the (logically abstracted) connection to patches
explicit.

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?


> I think what you are calling precedence I would call dependency (assuming
> it is a property of patches themselves rather than the representations of
> patches), and I think to define it properly you need to mention involve
> commutation, more specifically, its failure.

What I was aiming at with precedence was actually an extension of the
dependence concept; you can tell me if it's useful or not.  Obviously,
if two patches don't commute, then their precedence relationship is
clear.  But even if they do commute, there may be a preferred order of
composition.  If patch A adds several lines near to the bottom of a
file, and patch B adds several lines to the top, then patch B can be
applied either before or after A, but A cannot be applied after B
without resort to Theorem 2.  Thus, I would say that patch A implies a
precedence over patch B.

Again, you can let me know if this is a useful concept; it may be
superfluous given the way merge conflict resolution works.

> I would probably put this question in a sort of reverse order (it is an
> interesting question):  I would simply define the empty tree as the result
> of not applying any patches (maybe this is a bit too circular for you...),
> and then ask what dependencies certain patches must have.

This isn't too circular at all; it makes perfect sense.  When I wrote
that, I did not fully comprehend the thesis that a tree is nothing
more than an unordered set of patches.  Now I see that I was making
things much more complicated than they needed to be.

There is no spoon. :)

cheers,
--Mirian