[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Future of monotone

From: Markus Schiltknecht
Subject: Re: [Monotone-devel] Future of monotone
Date: Fri, 08 Feb 2008 15:45:14 +0100
User-agent: Mozilla-Thunderbird (X11/20080110)


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]