Re: [Monotone-devel] monotone win32 crlf questions

[Derek Scherger]

Nathaniel Smith wrote:
> I have a guess here: that diff algorithm operates on text lines.
> I bet it's interpreting both "\r" and "\n" as line ending characters,
> so "\r\n" looks to it like the end of one line, and then a blank line.
> (And then after it performs the diff on these doubled-up lines, it
> prints them out again with \r\n at the end of each, because you're on
> windows.)

It definitely appears to be doing something along these lines.

> I'm not actually sure if this should be considered a bug or what.  You
> don't have line-ending conversion enabled (see below), so Monotone has
> no idea what line endings you intended to use in the files being
> diffed, and "\r", "\n", and "\r\n" are all valid line endings in
> different contexts.

Probably user/configuration error more than a monotone bug.

> By default, these are both _disabled_; if you want Monotone to munge
> around with your files, you have to ask it to explicitly, by defining
> the get_charset_conv or get_linesep_conv hooks.  Monotone prefers to
> store text in LF (= "\n") format, so in this case it sounds like you
> might want to add on all your Windows boxen something like:
>   function get_linesep_conv(name)
>     -- Examples for leaving binary files untouched:
>     if (string.find(name, "%.jpg")) then return {"LF", "LF"} end
>     if (string.find(name, "%.png")) then return {"LF", "LF"} end
>     return {"LF", "CRLF"}
>   end

I'll probably turn that aound so that *.java and other known text files get recognized 
first and everything else will be left alone lest I mess up some binaries.

> Yes, Monotone takes care to always hash the normalized version of each
> file.  This means that in you're storing files in "\n"-mode in the
> repository but have them in "\r\n"-mode in the working copy, then
> sha1sum will no longer give you the correct hash... but Monotone will
> still get it right.

Ok, I somehow had the wrong impression that sha1sum was always going to produce equivalent 
results.

One more thing, as I understand it the presently stored versions of my files will be using 
\r\n line endings and presumably I need to clean these up myself. I don't expect that 
defining the hook above is going to do me much good until I clean up the files in my 
database. I suppose I could set the hook up so that the internal form is \r\n and set the 
external form to \n on linux boxes but this seems rather nasty!

Thanks for the info.
--
Cheers,
Derek