[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: rghetta
Subject: Re: [Monotone-devel] [PATCH] and RFC: binary files merging and hook
Date: Fri, 27 May 2005 21:44:23 +0200

Ok, I'll try to summarize the requests (and possible answers) so far:

Both Nathaniel Smith and Emile Snyder advocated the use of .mt-attrs,
perhaps coupled with the attr_init hook to automagically mark the files
at "add" time.
Howewer, the attr_init hooks receive only the filename, while the hook
needs also the file content to guess the file type if the name doesn't
IMHO, the guessing part is a necessity, requiring the user to manually
specify every binary file seem too harsh to me, especially because every
project has its share of non mergeable files, even monotone ;-)
The hook is here just to handle the corner cases (like file specific
merging tools), but I think monotone should make the "right" choice
Attributes seems also just not available at merge time.
Both of these issues need to be resolved before using attributes to
decide on merging.  Is a rewrite of the attribute system needed ?

Joel Crisp wrote: 
> I'd prefer a 'file type' attribute rather than a binary file attribute - 
> there are many types of files which may require specialist 
> merging (e.g XML) 
> or storage (e.g. super big video files which are stored external to the scm. 
The binary_file hook is used only to inhibit algorithmic merging
(perhaps a better name for the hook would be "disable_auto_merge").
Essentially, a "binary" file is treated as a text file with a conflict,
i.e. monotone will invoke the merge2 or merge3() lua hooks. 
The merge2/merge3 hooks receive both filenames and full file content,
thus by redefining them you can use choose a specialized merge tool
based on the file type (I made the example of gimp for merging images).
AFAIK, monotone doesn't directly support storing files externally, but
you can simulate it by storing only a "pointer" file and redefining the
mentioned hooks.

Glen Ditchfield wrote: 
> You base the text/binary decision on the name of the file.  How hard would it 
> be to base it on the contents of the file instead, the way the Unix 'file' 
> command does?  
The hook uses only the filespec, true, but if it returns nil, monotone will
check the file content for ASCII NULs and some other control chars.

Unless adding .mt-attrs support is more or less trivial, my proposal is
to merge the current patch to resolve the merging bug. Then perhaps we
could rethink a bit the attributes to have them available everywhere,
not just when dealing with the working copy or the manifest. 
After that, adding a "binary" or "disable_auto_merge" attribute should 
be easy.
What do you (collectively :-) think ?  



reply via email to

[Prev in Thread] Current Thread [Next in Thread]