[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Future of monotone
From: |
hendrik |
Subject: |
Re: [Monotone-devel] Future of monotone |
Date: |
Fri, 8 Feb 2008 19:11:41 -0500 |
User-agent: |
Mutt/1.5.9i |
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