[darcs-users] locking

Ketil Malde ketil.malde at bccs.uib.no
Fri Feb 24 10:16:10 UTC 2006


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

> The easier it is to commute syntactic patches, the
> more carefully you need to check semantic prerequisites

I'm not sure I follow you.  Could you give an example (of a LaTeX
or other textual document) where commutation across a word based diff
would break something and be less desirable than a conflict?  Would
this happen often enough compared to conflicts?

> I strongly suspect the reason that
> line-oriented hunks work as well as they do is that good style, if not
> syntax, in most languages is line-oriented.

In most *programming* languages.  Conversely, the reason they work
poorly for e.g. LaTeX documents is that good style isn't line
oriented. 

I'm (of course) not saying you should always do word-based diffs, only
for formats where line-based diffs work poorly.

> It's in the packages.  Check M-x list-packages.

Didn't work.  No matter, although I still don't see why a file format
somehow imposes restrictions on the diff algorithms.  Inconveniences,
yes, restrictions no.

> more than handle line-oriented text is the wrong idea (unless you want
> to turn it into Yet Another Editor That's Smart).

I agree.  Which is why I don't think it should do more, just do
differently. 

> You can probably get that down to O(n lg n) or better on average by

Sure.  I mean - do a linewise diff first, and then do a wordwise diff
on each hunk of changed lines.  Even with O(n²) behaviour, the cost is
now only an additive factor of O(m²) over the normal diff, where m is
words per hunk.

> Which is another reason why the algorithms should be under control
> of a scriptable editor....

As long as I don't *depend* on the editor to manipulate (apply, pull,
push, record..) patches or depend on separately distributed
functionality. 

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants





More information about the darcs-users mailing list