Line ending translation extension

[Stephen J. Turnbull]

Martin Geisler writes:

 > The way I see it, mentioning a file in .hgeol means that you no longer
 > want to manually control the EOL symbols used. Mercurial will take
 > complete control over it.

I basically agree with this (but I have little hope it will put "Paid
in Full" to the platform-dependent newline problem).  Also, the way I
interpret "no manual control" is that any newline function (as defined
in TR#14 on unicode.org) is treated as a newline, and canonicalized to
the internal representation on commit, subject to the following
caveat:

 > So even if you change EOL format in a file in your working
 > directory, the file wont appear modified to Mercurial.

I don't really like that idea.  I think Mercurial should take note of
any difference from the expected convention and warn about it, or
maybe even abort the commit.

 > When you commit, newlines of all kinds are converted to the format
 > specified in .hgeol:
 > 
 >   windows: convert LF and CRLF to CRLF
 >   unix:    convert LF and CRLF to LF
 >   native:  convert LF and CRLF to repository native format

Be careful.  At *commit* time, AIUI anthing that looks like a newline
is converted to repo-internal format, which probably should be LF.  At
*checkout* time, repo-internal format is converted to the specified
format, where "native" depends on the platform where the working tree
is being checked out (or updated).

I think that having repo-internal depend on the platform where the
repo was init'ed is a short cut to madness....

 > By the way, if you change the declared EOL format of a file by
 > editing .hgeol, you have to call 'hg debugrebuildstate' to make
 > Mercurial double-check the filter settings and doing a commit.

I don't understand this.  The repo's only knowledge about the newlines
in the working tree is contained in .hgeol.  Change that, force a
checkout of the file, and voila!  No?