[darcs-users] questions on patch theory

[Mirian Crzig Lennox]

droundy at jdj5.mit.edu (David Roundy) writes:
> 
> Yes, there could be a case where both change.  I don't think there is yet
> one in the current implementation, but I want to implement hunk moves
> (which would move a hunk of lines from one location to another, as you
> might guess).
> 
> So
> 
> hunk (at line 2)
> +hello world
> hunkmove (5 lines) (from line 1) (to line 10)
> 
> would commute to
> 
> hunkmove (4 lines) (from line 1) (to line 10)
> hunk (at line 11)
> +hello world

In general I see your point, but there is one twist I would like to
mention, which is that nothing forces you to describe a hunk relative
to the beginning of the file (as you do above); it is equally valid to
describe a hunk relative to the end of the file.  If you had done so
in your hunkmove patch above, then it would commute with the hunk
patch without modification, and the influence would go in one
direction only.  Similarly (although it doesn't help in this
particular situation), any hunkmove can also be converted into one
which moves in the opposite direction; (e.g. instead of lines 1-5
moving 5 lines down, the same hunkmove can be specified as lines 6-9
moving 5 lines up).

So, at the risk of making things even more complicated, a patch
describes a change not only across an infinite set of possible
commutations, but there may also exist equivalent permutations of that
patch which have different commutation properties.  I'm not sure if
this makes things easier, or if it just opens up a huge can of worms.

> There are a number of thorny issues in the commutation of hunks with
> hunkmoves--basically they come up whenever there is an overlap of
> boundaries--which is why I haven't yet implemented hunkmoves.  My plan is
> to implement them after I've released darcs 1.0, since they will take a
> while to debug and may introduce interesting bugs.  Even hunkmoves
> commuting with hunkmoves is a challenge, since you could end up splitting a
> hunkmove into two hunkmoves upon commutation.

This brings up an interesting issue on its own, one which is not
really covered in your theory: how are commutations on aggregate
patches performed?  If you have the composition MC, where M is itself
a composite patch, AB, then how is the commutation MC <-> C'M'
represented?  My naïve guess is to expand M and perform a three-way
commutation; i.e.,  { ABC -> AC'B' -> C''A'B' -> C''B''A'' }.
Is this correct?  

> I'm afraid that when hunkmoves are introduced the influence will get all
> messed up, since removing a hunkmove C from the context of both A and B may
> change their influence relationship.

Pity.  It's becoming clear that influence as I envisioned it is not
going to work, at least as a first order simplification.  Well, the
real world is messy like that. :)

--Mirian