EOL extension

[Jesse Glick]

Mark Hammond wrote:
> of the problems win32text has, mis-classifying content doesn't 
> seem to be one of them.

I would concur - we have been using win32text for a couple of years on a set of repos containing around 100k files, with no misidentifications of text vs. binary content 
that I am aware of (including text in East Asian languages with various encodings). The test for presence of at least one NUL (0x00) seems to work remarkably well; there 
has been no need to configure file extensions or whatnot.

> One set of problems was caused by 
> people having different EOL rules which caused files to "flip" between 
> EOL convention depending on who last edited it and checked it in.

This can be prevented by using the forbidcrlf hook in win32text. We configure it as a pretxnchangegroup hook, so text files in public repos are always in LF format - 
therefore 'hg annotate' and merges and so forth are never broken by line ending issues. We also recommend all developers (on any platform) to configure it as a 
pretxncommit hook in ~/.hgrc or its equivalent so as to catch mistakes early. If a new developer does commit a bunch of changesets and can't push them, it is possible to 
use export, strip, and import to recreate those changesets (a single command to automate this would be great), but this should only ever happen to a given person once. 
Making the hook accept "intermediate" changesets with CRLF so long as they were "later" (in the same branch? ...) corrected would be possible, but then the repository's 
history would be permanently impaired, possibly for a lot of files, so we don't do this.

> Some dances which involve "diff > me.patch" and 
> "patch < me.patch" will insert \r\n line endings regardless of what the 
> file already has.

The encode hook handles this in the case of files in the working copy. There can still be problems on Windows with import and transplant, since some Hg code seems to not 
be written with encode/decode hooks in mind.