There are 2 separate questions - (1) what is held in the repository, and (2) what is in the user's workspace. The two clearly interact. [...] As regards (1), I assume that for "text" files, a consistent EOL convention (assumed LF) should be used in the repository.
Correct. I believe Martin (the other one) proposed to make it configurable. I agree that using LF in the repository is sensible. Wrt. "should": there is the debate whether intermediate revisions can deviate from that requirement.
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.
I would say so, yes. One consequence of that is that if you change your mind in hgeols, you need to commit all files that now fail to conform. This is what happens with svn, and it may be tricky to implement as you need to commit files that didn't change on disk (say you switch from native to CRLF on a Windows checkout). OTOH, even if you do store all text files in LF in the repo, then you would still have the problem for files that go from unspecified eol-style to a specified one. So changing hgeols is tricky, period.
- Some "binary" files which should never be converted - Some "text" files, which must be held in LF form in the repo
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.
Not by technical means, no. In the developer FAQ, there will be clear directions, and you better follow them - or need to accept the blame if you made a mistake because you ignored them.
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.
Technically, yes, it is only needed on Windows. The desire to have all users use them come from the wish that problems with the setup will be detected earlier. E.g. if the extension stops working with a new Mercurial version, and all users use them, there is a larger motivation to fix them for all users. Things that the extension can do for you on Unix: - check that the syntax of .hgeols is correct; this may affect Unix users which try to edit it - check that all text files have consistent line endings, and refuse checkin if they don't. This may become relevant if a Unix text editor tries to edit a CRLF file, and doesn't quite detect that.
2. Allowing text files to be checked out in whatever form the user prefers seems complicated. The alternative would likely be to say test files are checked out in "native" form. 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.
It's consensus, and it's also what subversion does, and CVS did.
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? 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)?
I think everything you can imagine is also realistic. For the less-realistic cases, it may be better if the commit is refused rather than silently fixing it, since the user operated the system in a surprising way - so he may actually have meant to do it that way. One specific case is recent autoconf, which put a CR character into configure, completely breaking svn's eol handling. Regards, Martin