Re: [Monotone-devel] Future of monotone

[hendrik]

On Fri, Feb 08, 2008 at 03:45:14PM +0100, Markus Schiltknecht wrote:
> 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.

Agreed.  So far I haven't found anything that does a decent job with 
text.

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

Yes.  That's how I see such a feature fitting into monotone.  I was 
hoping for something of the sort when people were discussing Windows vs 
Linux line endings.
> 
> >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.

Interesting.  I wonder how?

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

It certainly could.  Which is why I've hesitated using it on XML.  
Though I've heard some people are having success with it anyway.

> So what's right is very dependent on the content, IMO. The line 
> based approach simply fits source code quite well, I think.

It does.  A friend of mine once decided that source code should be 
treated as poetry by a word processor.  Lots of lines.

-- hendrik