Re: [Monotone-devel] Spaces in filenames, UTF-8, and newlines (was: monotone & CVS import)

[Nathaniel Smith]

On Wed, Nov 12, 2003 at 05:08:26PM -0500, graydon hoare wrote:
> eh.. not just yet. problem is, the only thing I can think of which is
> acceptable from a user's perspective is transparently washing and
> unwashing newlines when reading and writing files. but that is so
> uninspiringly against the general design (binary-clean, SHA1(file) ==
> version) that I can't imagine turning it on by default.
> 
> maybe permit a (default undefined) hook, and if you put:
> 
>  function wash_line_endings (name)
>       if (string.find(name, "%.c$")) then return true end
>         return false
>  end
> 
> in your .monotonerc, you give up being able to run sha1sum on your .c
> files anymore, and I have a strong statement in the manual about how
> this makes sha1sum useless on your files. would that do?

I think it would be cleaner to use a .mt-attr for this, and add a hook
to let people set default attrs on files.

function set_default_attrs(name)
    if (string.find(name, "%.c$")) then
        return { {"line_endings", "convert_to_host"} }
    end
    if (string.find(name, "%.vbasic$")) then
        return { {"line_endings", "force_to_crlf"} }
    end
end

or something.

Of course, this would require the ability to either make attribute
hooks that can modify files on their way in and out of the working
copy, or else hard-code the attribute name into monotone.  I guess the
argument both for and against each solution is generality; on the one
hand, hard-coding and special cases are to be avoided, but encouraging
people to create their own arbitrary content-munging hooks might be a
bad idea.  I also can't think of any real use cases.  ($Id$-type
expansion is sorta like this, but has other issues -- like how you
handle diffs involving such expansions.)

-- Nathaniel

-- 
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould