monotone-devel
[Top][All Lists]
Advanced

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

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


From: Joel Crisp
Subject: Re: [Monotone-devel] [PATCH] and RFC: binary files merging and hook
Date: Thu, 26 May 2005 16:06:27 +0100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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 {yes people do this}). Using a type-manager approach (see clearcase for an example of this) allows a lot more flexibility, and allows people to register new types which were unknown at design time.

Note that there is no reason why someone may not want a structure aware merge 
tool for some types of source code files either.

Using a hook to deduce the initial type sounds fine tho' so long as the user can change that hook and correct the attribute if the deduction is wrong.

Joel
Nathaniel Smith wrote:
On Wed, May 25, 2005 at 12:33:04AM +0200, rghetta wrote:

If the hook returns nil, the file will be treated as binary if the monotone function guess_binary() returns true, i.e. if the files contains NUL bytes or a selection of other ASCII control chars (for example, STX and ETX).


Another possible way to do binary support, for discussion:
  -- have the merger peek at .mt-attrs, and if a "binary" attribute is
     set on a file, consider it binary.  (Currently nothing in .mt-attrs
     has hard-coded behavior, so this would be a change.)
  -- use the cool new attr_init hooks to automatically guess at "add"
     time whether each file is binary.
  -- never again automatically touch this attribute; let people set it
     to what they want, if they want

Another possible way to do binary support, for discussion:
  -- just use guess_binary() on the data at merge time

I don't tend to store binary files under VCS, so I don't have as much
of an intuition about what the nicest way to do so would be; it'd be
good to hear opinions from those actually affected by this :-)

-- Nathaniel





reply via email to

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