[darcs-users] break line, combine lines, add/delete whitespace as patch primitives?

David Roundy droundy at abridgegame.org
Wed May 5 10:50:49 UTC 2004


On Wed, May 05, 2004 at 03:28:37AM -0700, Adam Megacz wrote:
> 
> Kevin Smith <yarcs at qualitycode.com> writes:
> > That would work if darcs could automatically detect that it should use
> > one of the new primitive types. I don't think they would be helpful if
> > they required manual operation like the token-replace patch does.
> 
> Clearly.  But it's unambiguous -- Darcs should use the simplest diff
> possible, where "add linebreak" or "remove linebreak" is "simpler"
> than deleting two lines and adding one (or deleting one and adding
> two).

This sort of patch is definitely in the plans--but only after darcs 1.0 is
released.  I know I keep saying that, and never releasing it, but we keep
finding bugs...

I think when this new sort of patch is introduced (and obviously there'll
have to be some thought about what sort of primitive is appropriate), I'll
probably introduce something like the "binaries" file which will allow you
to configure which sorts of files are candidates for the new patch.  In C
code, you probably don't want that sort of trickiness, and certainly not in
haskell code (unless it's literate...).

My current leaning would be to introduce the idea of a word-wrapped
paragraph, which obviously brings up the question of how exactly that would
be defined.  Obviously there would be a "number of columns", which might be
tricky when commuting two word-wrapped-paragraph patches.  I think it'll be
tractable, but of course the real test is in the implementation.

> > As an alternative for this case, what about being able to treat a file
> > as a stream of "words", rather than a stream of lines? I'm not sure
> > exactly what the delimiters would be, or how this mode would be chosen,
> > but this would certainly benefit many text files.
> 
> This starts moving closer to the tree transform.  Ideally (if we all had
> infinite time to spend implementing this stuff) you could give darcs a
> grammar for C++ and it would understand that adding parenthesis around an
> expression that doesn't need them is a "benign" change that could be
> ignored (or better yet, re-ordered) if it caused a conflict with a
> non-benign change.

Once I get darcs 1.0 out (and I really do believe it'll be pretty soon),
the first thing to do is to look again at the merge problem.  I have a few
ideas how I can make the mergin of conflicts more elegant, which may make
things more efficent as well.  Unfortunately, it may be very invasive, so
it'll take some thought.

After that I'll look at working on new patch types.  I'll try to see how
easy the tree transform idea is to implement, and if it isn't so easy then
I'll implement some new patch types the "hard way".
-- 
David Roundy
http://www.abridgegame.org




More information about the darcs-users mailing list