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

[hendrik]

On Thu, Mar 05, 2009 at 09:57:06AM -0800, Zack Weinberg wrote:
> 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.

Excellent!

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

Would the following be an effective test?

               A
              / \
             /   \
            B     C

where B and C involve changes in different parts of the same line, and 
then try to merge B and C to see if there's a merge conflict?

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

That would make it possible to test how things work with a byte-merge.  
Chop the entire file into one-byte lines, ..., assuming monotone uses a 
line-merge, that is.

-- hendrik