[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 2.0.0.9 (X11/20080110) |
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