[darcs-users] hunk move as primitive change

[Ganesh Sittampalam]

Hi Ben,

On 01/05/2013 00:51, Ben Franksen wrote:

> This is something I have on my wish-list for longer than I can think. The 
> idea is quite simple: a primitive change type that says "this sequence of 
> lines moved from file X line N to file Y line M". Here, X and Y need not be 
> different, i.e. a hunk move need not be between different files.

I've wanted this feature for a long time too! I've actually spent some
time thinking about it already - see below.

> Even though the idea is simple, this is certainly not "low hanging fruit". 
> It would be necessary to somehow record that the context for changes further 
> down in the affected files translates up resp. down (by the number of lines 
> moved), and to update this information when commuting such a change with 
> other changes. On the other hand, for regular hunks we do that already, so 
> maybe it is not that difficult after all.

I agree in principle it's not too hard, but I think there are quite a
few details to get right. One technical issue with commuting hunks in
general is whether to do when two hunks are touching - you want to make
commute succeed in as many situations as possible but not make it ambiguous.

I started working out the rules for commuting hunk move a while ago, and
concluded that there are quite a lot of rules needed for the different
cases - if commuting two hunk move patches on the same file then you
need to worry about the ordering of four different positions in the file
(source and target of each move).

My working view right now is that it's probably best to treat hunk move
as a "cut" and a "paste" operation, internally. [They shouldn't be
exposed to users, otherwise we end up having to manage a clipboard!]

However the rules will still be quite complicated and my feeling is that
we need some mechanical verification/derivation to be reasonably sure
that they are correct.

> In any case adding a new primitive
> change type most probably counts as a "deep" change to the Darcs code; and I 
> wonder if the repository format would have to be adapted and whether this 
> could be done in a backward compatible way.

I think it's difficult - at the very least, old clients would never be
able to understand the new patches and in particular know how to merge them.

One of the things we need to do before we start adding new patch types
is to figure out ways of managing this kind of upgrade in as painless a
way as possible.

Cheers,

Ganesh