[darcs-devel] hunk moves as a new kind of prim patch

Ben Franksen ben.franksen at online.de
Sun Feb 25 19:57:29 UTC 2018


Am 24.02.2018 um 20:49 schrieb Ben Franksen:
> Am 24.02.2018 um 20:17 schrieb Ben Franksen:
>> I have started to implement hunk moves, in particular I have worked out
>> a number of commutation rules, implemented them, and am now in the
>> process of debugging them with the (invaluable) help of the existing
>> unit tests.
> 
> I have a question regarding one of the properties, namely
> commuteCoalesce. Do we really need it to hold?
> 
> It fails when hunk moves are involved. This is expected: a hunk move
> followed by a single hunk might commute, but coalescing the hunk with
> another hunk can make the commute fail, e.g. because the hunk now spans
> more lines.

During my tests (I am running with -qc 2000) I found that merely
allowing the relaxed hunk commutation rules breaks this property. Here
is a simple counter example (files elided for clarity, all hunks are in
the same file):

 X = Hunk 2 b ø
 Y = Hunk 1 a d
 Z = Hunk 2 c e

With an initial file content of abc we have

 X : abc -> ac
 Y : ac -> dc
 Z : dc -> de

Then, under the relaxed rules, X commutes with (Y:>Z) but not with the
coalesced

 YZ = Hunk 1 ac de

The point here is that coalescing looses information and this
information was what allowed us commute X past Y and Y separately.

With the current rules this cannot happen because hunks with touching
source or target intervals commute only if both source and target
intervals are non-empty. Perhaps this has been the reason why the more
restrictive rules have been imposed in the first place.

However, this again raises the question whether we actually need this
property to hold. AFAIK coalescing is only used with unrecorded changes.
For instance, when unrecording a patch, darcs (AFAIK) commutes
unrecorded hunks behind pending, if possible, so they can be dropped
from the pending patch; afterwards coalescing is done on the remaining
prims. I fail to see how violating commuteCoalesce would be a problem
with this or any other operation on unrecorded changes.

Cheers
Ben



More information about the darcs-devel mailing list