Re: [darcs-users] hunk move as primitive change

2013-05-01 Thread Petr Pudlák 
Hi,

an excellent idea. It has troubled me for a long time that when someone
moves a piece of code to another file, it's basically impossible to see if
there were any changes in the block or not without a very thorough
examination.

  Best regards,
  Petr


2013/5/1 Ben Franksen benjamin.frank...@bessy.de

 Hi Everyone

 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.

 To my knowledge no existing VCS has such a feature. There are two
 advantages
 I expect:

 (1) Moving code around is something I do regularly in the process of
 cleaning up my (or other's) code. Currently such changes are represented
 (e.g. when using record or whatsnew) as remove these lines from file X
 line
 N (long block of code follows), add these lines to file Y line M (another
 long block of code follows). The remove and insert changes need not even
 be
 adjacent to one another (they typically are not) and even if they are it is
 very hard for the human eye to spot small differences in a long stretch of
 text. So if the tool told me I have a move (or I could tell it that this is
 the case) then I could be confident that no functional change occurred.

 (2) A hunk move commutes with changes /inside/ the hunk, or at least I can
 see no reason why it should not. This is not the case for the way such a
 move is represented now (as a remove and insert). This would mean more
 changes commute and thus less (accidental, unwanted) conflicts.

 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. 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.

 BTW, a better record command as in the GSOC proposal (which I find very
 promising) could be tought to detect hunk moves and present them to the
 user
 as such. It could even propose to record a move if there /are/ additional
 changes inside such a moved hunk, i.e. separate the move from (minor)
 changes made to the affected lines, using some kind of similarity measure.

 I would love to hear what you think about that.

 Cheers
 --
 Ben Franksen
 ()  ascii ribbon campaign - against html e-mail
 /\  www.asciiribbon.org   - against proprietary attachm€nts

 ___
 darcs-users mailing list
 darcs-users@darcs.net
 http://lists.osuosl.org/mailman/listinfo/darcs-users

___
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] hunk move as primitive change

2013-05-01 Thread 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

___
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users