[darcs-users] darcs conflicts/dependencies -- is patch theory the place to start?

AntC anthony_clayden at clear.net.nz
Mon Sep 17 05:58:05 UTC 2012


Stephen J. Turnbull <stephen <at> xemacs.org> writes:

> 
> AntC writes:
>  > AntC <anthony_clayden <at> clear.net.nz> writes:
>  > 
>  > > 
>  > > > You might also be interested in the following paper:  
>  > (Loh/Swierstra/Leijen Principled Approach -- henceforth L/S/L)
>  > > 
>  > > The problem with that approach is that a practical VCS only gets
>  > > to see the repo intermittenly (at record points).
> 
> Note that we should s/practical/standalone/ here.  In an editor like
> Emacs it would be trivial to record all operations at the character
> level (Emacs already records all operations).
> 

Thanks Stephen, I'm not convinced that character-by-character recording would 
always reveal the programmer's intent. Take this example:

- Edit file F, select all, copy, quit
- Remove file F
- Add file G
- Edit G, paste, save, exit

Now did the programmer intend merely to rename F to G? git would take it they 
did (I'm guessing).

Of course there might be all sorts of other keystrokes interleaved in those 
steps. In particular you might find much typing followed by deletes, 
copy/paste to change sequence, etc.

There's a more 'patch-theoretic' difficulty with guessing the programmer's 
intent: we know which keystrokes they used in the context (DAG) where they 
editted in branch A. We also know the keystrokes for t'other programmer 
editting in branch B. But when we merge branches (or pull patches) the VCS is 
trying to guess what the programmer *would have keyed* in some context they've 
never seen.

Perhaps going by keystrokes would make the context too restrictive? Perhaps 
waiting for 'record points' helps the programmer better to show their intent??

(Just sayin')

AntC



More information about the darcs-users mailing list