[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] monotone win32 crlf questions
From: |
Derek Scherger |
Subject: |
Re: [Monotone-devel] monotone win32 crlf questions |
Date: |
Fri, 02 Jul 2004 19:59:49 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040602 |
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