Paul Moore writes:
The result is that user workspaces *may* (quite probably, will) contain files with a mixture of line endings if care is not taken.
Yes. Under your "fixed-EOL-files-are-binary" scheme, this is guaranteed for Unix systems.
As regards (1), I assume that for "text" files, a consistent EOL convention (assumed LF) should be used in the repository. It's not clear to me what should be held in the repo for the files requiring specific line endings - my instinct is that they should be treated as "binary" and stored in the repo with the mandated line endings, and checked out unchanged.
Why? Files that require specific line endings are in general used in platform-specific ways. So checking them out with the platform's normal line ending should work fine.
My view is that how I store text files in my workspace is entirely up to me (and the capabilities of my tools). So, how files get checked out should not be centrally mandated.
Your tools will be able to work with the native EOL convention, or you wouldn't be able to stand using them. In general the extension should default to checking out with the native convention. If you really want to change that, you can; there's nothing the server can do to mandate what's in your workspaces. The "mandate" here is simply the default extension that Python and/or Mercurial will distribute to help developers avoid having their pushes aborted for incorrect EOLs.
So, the issues:
1. Given that the "problematic" tools (notepad and Visual Studio) are Windows tools, we seem to be back to the idea that this extension is only needed by Windows developers. As I understood the consensus to be that the extension should be for all users, I suspect I've missed something.
What you've missed is that developers *of* the Windows port are not necessarily developers *on* Windows. If we treat these as text files and check them out in the native convention everywhere, then it doesn't matter if you edit them on Unix or Windows, when you check them out and build on Windows it Just Works[tm]. I have never heard of a Unix cross-IDE port of Visual Studio....
2. Allowing text files to be checked out in whatever form the user prefers seems complicated.
It's not a question of "allow". AIUI, you won't be allowed to push a commit with broken line endings to the public repo. This is too much of a burden to impose given the wayward behavior of existing tools, so an extension will be distributed that does the checking (and any needed conversion) for you. If you don't like that extension, you can change it; it shouldn't be too difficult. Eg:
That works, but would irritate me as I work on Windows, but prefer strongly to use LF line endings (yes, I realise that makes me an oddball...) I'd put up with it if it was the consensus to do this, of course.
You don't need to. In that case I would guess that you are at very low risk if you disable the checkout side of the extension.
3. Is there a realistic possibility that a user could edit one of the CRLF-requiring files with a tool that converts it to LF?
Yes. It happened occasionally in XEmacs's CVS repository, and caused great consternation among Windows testers.
If so, is there a need to trap that programmatically (as opposed to simply accepting that this equates to the individual accidentally breaking the build, no worse or better than checking in a C file with a syntax error)?
It's worse. Until the problem is fixed, the people who need a different EOL convention are working with a file with breakage on every line. Furthermore, that breakage may be quite silent, eg, if you use XEmacs to edit on Windows but Visual Studio to build. With Emacs it's easy enough to change -- if you recognize the breakage.