Re: [Monotone-devel] Re: Text under revision control

[Zack Weinberg]

On Thu, Mar 5, 2009 at 7:18 AM, Hendrik Boom <address@hidden> wrote:
>> I've not integrated wdiff with monotone's external diff hooks, but I
>> don't see why it couldn't be done.
>
> I've considered these matters, and it raises a few questions.
>
> (1) With monotone as it is now, would there be incompatibilities if I
> were to use a wdiff merge hook, and I sync with other data bases that do
> not?

There's a fine distinction you may not be aware of.  The "deltas"
stored in the database are generated by a variation of the Xdelta
algorithm (see xdelta.cc) which is byte-oriented, doesn't care about
line endings, and isn't particularly human-readable.  The
human-readable diffs generated by "mtn diff" and similar commands are
line-oriented, but not used for internal purposes.

For instance, the change in revision
ff4211218fda1c066b669b9a6bdf91a4cd44da9f shows up like this in the
output of 'mtn diff':

-AM_CXXFLAGS = $(AM_CPPFLAGS) $(PCH_FLAGS)
+AM_CXXFLAGS = $(AM_CPPFLAGS) $(PCH_FLAGS) -fpermissive

but what's actually in the database for that file delta is:

C 0 16246
C 16259 15889

(file deltas in the database go backward in time, so this *undoes* the
the change shown above).

So the answer to your question (1) is no, it won't cause
incompatibilities, because the algorithm used to compute the contents
of the database is totally independent of the merge algorithm.

> (3) Is there a technical reason why the default merge views files as
> sequences of lines to be inserted, removes, or kept instead of some other
> view, such as a sequence of bytes to be inserted, removed, or kept?  The
> latter would seem to be able to reduce the number of merge conflicts we
> encounter, and increase the number of file formats we play nice with.

I'm not actually sure whether the default three-way content merge is
line-oriented or byte-oriented.  As you say, having it be
byte-oriented would probably reduce the number of merge conflicts
kicked to the user.

Note that what the user actually sees for the merge conflict is a
function of the 3-way merge program they use -- we just give it the
three files.  There's pretty wide variation in smartness across the
set of mergers we support.

> (2) The simplest such hook would seem to be a procedure that breaks the
> input file into s sequence of one-word lines (more or less) then calls
> monotone's default merge to process those, and then converts the result
> back.  Is a default-merge callback available to the lua?

There isn't now but there's no reason we couldn't add one.

zw