Re: [Monotone-devel] Future of monotone

[hendrik]

On Tue, Jan 29, 2008 at 09:30:24AM -0800, address@hidden wrote:
> On Mon, Jan 28, 2008 at 05:04:33PM +0100, Markus Schiltknecht wrote:
> 
> > Thomas Keller wrote:
> > >So where lacks monotone the most?

There's the question of editing files.  Normal (say) English text,
divided into paragraphs.  It's not unusual for a document to fork into 
several versions, even when maintained by a single author, for which 
corrections have to be propagated -- the usual problem for which 
revision control is the answer.

I believe monotone uses a merge algorithm that chooses lines from the 
various ancestors.  Now the trouble is that small edits in a paragraph 
can completely change the way a paragraph is split into lines.  If on 
another branch a different small edit has been made, the result is a 
merge conflict.  Looking at it manually to resolve the conflict, is it 
hard to even see where the actual changes have been made,  because the 
differences in line division overwhelm the eye.

It's possible to avoid the variations in line division by adopting a 
convention wherby in the file itself you only use explicit newlines
between paragraphs, relying on the editor, or printing software to use 
sensible formatting for long lines.  (this is a small step in the 
direction of a sensible word processor).  But then the lines become very 
long in themselves, and, although variations in layout will no longer 
result in differences to be resolved, any changes that do occur are lost 
in even more unchanged text.  The practical result is much the same as 
with the previous regime.

What seems to be needed is something that recognises differences at the 
word -- or even character -- level.  (When merging documents by hand, 
I'e found wdiff quite useful.) Is there any chance of getting 
something like this?

If it could also detect blocks of text that have been moved, of course 
that would be awesome.  But I suspect dealing with that is 
difficult, or it would already have been done for computer programs.

I won't even ask about proprietary word-processor formats that almost 
encrypt the data.  They're beyond the pale, and I won't even consider 
using them.  Stuff that can be edited with an ASCII or UTF-8 editor with 
minimal in-band markup is all I need.  I suspect Open Document Format 
satisfies this description, as long as the word processor doesn't go 
overboard on overspecifying everything (too many still do).

-- hendrik