Re: [Monotone-devel] [PATCH] and RFC: binary files merging and hook

[rghetta]

Glen Ditchfield wrote:

> On Tuesday 31 May 2005 00:27, rghetta wrote:
>
> > Even with the add-time hook you need two functions: one for the add
> > hook, to mark those files you don't want merged by monotone internal
> > algorithm, another for choosing wich merge tool to use.
>
> Why can't there be one function that examines the files and decides to run the 
> internal merge algorithm on some kinds of files, and to exec external tools 
> on other kinds of files?
Because at add-time you add an attribute to the file, i.e. something 
wich becomes part of the revision and thus become the same for everyone 
who syncs with you.
At merge time you use this information to choose wich tool to use, i.e. 
something everyone could handle differently.  For example, even on plain 
text files I use kdiff3 to merge, while others prefer xxdiff, ediff, 
meld ...
In principle we can encode a full filetype as an attribute (perhaps even 
the mime-type, like subversion), but still you need two functions. One 
at add-time to choose the filetype, another to invoke the right merge tool.

> I don't know anything about monotone's internal structure, and I don't want to 
> know, and that's the sort of stuff that changes from release to release 
> anyway.  From out here, the internal merge algorithm looks like just one of 
> the possible choices of merge tools.  I don't see it as being so conceptually 
> different from other merge tools that it has to be handled by a separate 
> mechanism out at the user-level hook API.
The internal merge is different because it represents a fully automated 
first try.
If the internal merge can't resolve cleanly, it needs to escalate the 
merge to the user, and you want to choose your preferred tool to do this 
merging.  Nothing says you want to use the same tool to handle every file.
Besides, "to exec to external tools" you need to call an hook anyway, 
because every tool wants different options, returns its output 
differently, and so on.

Riccardo