Re: [Monotone-devel] Future of monotone

[Markus Schiltknecht]

Hi,

address@hidden wrote:
> 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.

That might apply to text files, but not so much to source code, which is 
monotone's primary concern.

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

Well, the internal merge algorithm is line based, yes. But if it decides 
it cannot merge automatically due to conflicting lines, it invokes 
whatever tool you want it to invoke to resolve the conflicts. Often 
enough, my kdiff3 can cleanly merge everything, where monotone couldn't.

I don't think making monotone's internal merger finer grained buys us 
much. What I'd rather like to see are special, content aware mergers, 
i.e. for XML or plain text, etc..

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

IIRC the internal merger detects moved blocks *of lines*, yes.

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

ODF is an XML format, right? So a special XML merger would be great to 
have. However, I fear simply using a finer grained, probably even 
character based merger could even cripple your XML file - or C source 
code. So what's right is very dependent on the content, IMO. The line 
based approach simply fits source code quite well, I think.

Regards

Markus