Re: [Monotone-devel] Re: line endings with 0.31

[Larry Hastings]

Bruce Stephens wrote:

Larry Hastings <address@hidden> writes:
  

eol conversion should be /disabled/ by
default, and should be /enabled/ with a setting.
Principle-of-least-surprise there.
    

I'd have thought the least surprising would be to have the conversion
enabled for text files.  That means you could pull net.venge.monotone
and checkouts would have their text files sanely readable on Windows,
and files checked in on Windows and checkout out on Unix would be
readable.

I think the more important principle-of-least-surprise operating here is "my SCM doesn't fiddle with the content of the files I store and retrieve without my express permission".  And keep in mind that my definition of what could reasonably be considered "text files" may be different from yours.

In practice, almost all programmers' editors on Windows--and UNIX too--are smart about auto-detecting and preserving the file's EOL convention.  The only editor I ever use that has trouble is "Notepad", and really that's just one more sign that I need to stop using "Notepad".


While we're on the topic, here's a real-world problem I learned about recently.  I fixed the MSVS 6 build process for Python 2.5 and 2.6, and in so doing I found the project files were marked "binary" in SVN.  This inconvenienced me, because SVN's diff won't generate patches for "binary" files.  I said "why's that?", they said "because MSVS 6 is really touchy about the CR/LF EOL convention in its project files."  I said "as long as it's consistent it won't hurt anything".  They said "sure, but if we do svn checkout on UNIX, then copy the files to Windows, the project files would get written out with just LFs, which breaks MSVS reading 'em".  This did happen to them in practice, but I forget where; maybe it was with buildbots?  Maybe they build the official source distributions on UNIX machines?

This suggests a nice-to-have feature, as long as we're thinking about the problem.  Obviously 99.999% of the time you have either "yes it's a text file, and yes do eol conversion" or "no it's not a text file, and no don't do eol conversion".  But for these project files, it'd be nice for monotone to preserve the EOL conventions and still do intelligent merging.  (And maybe store changes using deltas?)  So perhaps monotone could straddle the line here: "yes it's a text file, but no don't do eol conversion on it".


Once again, I reflect: if I had a time machine, after I made my millions, I'd go back and cause MS-DOS 1.0 to use just LF for EOL and "-" for program options, freeing up "/" for use as the directory separator under MS-DOS 2.0.  How many hours of our lives have been wasted on these needless differences?  ("And, Tim, while we're on the subject, we need to talk about these 'drive letter' things...")

Cheers,


larry