Line ending translation extension

[Stephen J. Turnbull]

Adrian Buehlmann writes:

 > Since we switched almost all source files to use LF line ends only,
 > I haven't heard of any problem ever since. Contributors send patches
 > to the -devel mailing list, and these are applied without problems.

Sure, because the mail system does exactly what the proposed extension
does, except that it requires the user to handle true binaries
differently.  Didn't you realize that?

However if people check them in directly, I would expect the
occasional problem where Windows users check in new files with CRLF,
and they have to be converted.  Martin v. Loewis testifies that every
Windows committer in Python on made that mistake until features of
Subversion were used and scripts were written to manage EOLs.

 > In short, I recommend to agree to using LF line ends for any
 > project that does cross platform development. It's simple and
 > solid and doesn't require awkward extensions that tweak files
 > on check-in.

Sure.  So do almost all Mercurial and git fans, and it works fine,
except for an almost indetectable grumble from the Oppressed Minority.
That's why Mercurial doesn't have a decent EOL handler (decent by the
standards of people who want such things).

For that matter, I recommend the same thing.  But Important
Contributors to Python very much want this feature, and both the
editors of the "Let's Do DVCS" and "implementing Mercurial" Python
Enhancement Proposals acknowledge it as essential to implementing the
migration.  So that recommendation is a dead letter for Python.

 > Personally, I would never ever use any piece of software that
 > dares touching my file contents during checkin. From a VCS,
 > I expect to check in exactly what I have on my disk in my
 > repo, nothing else.

Sure.  So you don't enable the extension, and (with internal = LF)
both you and the project are happy.  As long as the project uses an
EOL convention your editor understands, and your editor maintains it,
you're OK (except for new files).  You'd probably be pretty displeased
with the result if the project followed the recommendation of Unicode
Technical Report #14 and used U+2028 for the line separator, though.
<wink>

 > And I want to get the exact same back on checkout, no matter on
 > what platform I currently have my repo.

Sure.  But there are people who have strong preferences for platform
native conventions (or for tools which demand platform native
conventions, which ends up in the same place).  And that's where your
whole scheme founders for Python, AIUI.  A lot of Windows developers
of Python feel this way.