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

[rghetta]

On Fri, 2005-05-27 at 20:13 -0700, Nathaniel Smith wrote:
> On Fri, May 27, 2005 at 09:44:23PM +0200, rghetta wrote:
> > 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
> > matches.
> 
> But, the file is sitting right there on the filesystem, and the hook
> can run arbitrary code.  For instance, it could peek at the file to
> see whether it looks like it's binary.
I'm a bit worried about efficency, here. Add already reads the file ? If
yes, then monotone will read the file twice, and this could have a
noticeable impact on add performance.

> > 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 ?
> 
> What would this rewrite do?  (It's entirely possible we do need one,
> the .mt-attr concept doesn't seem fully developed yet to me, but I
> don't see what you're getting at here.)
> 
> At merge time we know the file names, and we know what revision they
> come from; in principle there is no reason we can't grab the .mt-attrs
> file from that revision and see what it says.
I was wrong. Attributes *are* available at merge time. Looking better at
the merging code, I found we already do that to get the file encoding.
It's parsing the attribute file(s) everytime, and this could have an
impact on merging performance for large trees, but handling the binary
attribute is trivial.

Riccardo