my strategy on implementing line-endings (eol) support

[Talden]

> > > | 3) text files with native/LF/CRLF/CR line-endings
>  > >  Actually, I've never understood (3) - which is also apparently
>  > >  what subversion does.
>  > >  To my mind, a text file either has EOL left alone (ie, "exact") or
>  > >  has EOL style set to native (where line ends are transformed).
>
>  > At least one case comes to mind - A build process, executed on windows
>  > and  containing *nix shell scripts in the distribution (and possibly
>  > edited by devs on either platform), needs to enforce shell scripts as
>  > LF not CRLF or the distribution will be incorrect.
>  >
>  > So the VCS protects the distribution by ensuring that, at commit, EOLs
>  > are normalises and checks out to LF regardless of platform.
>
>  Thanks for the clarification, but I'm still a little confused.  I don't see
>  why this is any different to the answer you just gave to Ian:
>
>  > Files with no EOL conversion rules will store exactly what you commit.

No conversion means a file would end up with mixed EOLs - definitely
not the same as normalising them to any of the EOL conversion rules.

>  So just store these scripts with no EOL conversion (although in this
>  specific case, "native" would seem better, so users could edit the scripts
>  on Windows Notepad and still run then on  *nix)

Assuming I used 'native' for shell scripts and I, a windows user,
checkout and build a distribution which is then installed on a *nix
machine, any shell scripts would fail.

Less certainly, if I used no normalisation and built a distribution
which is then installed on a  *nix machine, the shell scripts MIGHT
fail if a windows user has edited them with a tool that added CRLF
EOLs.

>  It seems to me that accidently changing the *stored* EOL style on the build
>  scripts is no worse than accidently changing it on any other text file -
>  indeed, the build script may be preferred as the error can be seen earlier
>  as the build breaks :)

In this case it wouldn't be the build that broke but the install. That
is, you cannot test run all of your scripts on the machine that
performed the build if those scripts are targeted at a different
platform (and the distribution is a multi-platform distro).  Having
the VCS normalise and enforce an EOL rule despite multiple platforms
being used for editing reduces the risk of developer error reaching
customers.

>  1) a flag to allow EOL transformations be applied to a file at checkout and
>  checkin.  It seems "none" and "native" are the only real use cases here.

I disagree, see above.

>  2) a desire to prevent *any* text file from "accidently" having the EOL
>  style changed in the repository (ie, after any "native" transformations are
>  applied)

The desire is, for text-files with EOL rules applied, to have the VCS
normalise EOLs and express them in a defined form, either platform
native or one specific representation.

--
Talden