Re: fixing files committed with wrong eol-style

----- "Geoff Worboys" <geoff_at_telesiscomputing.com.au> a écrit :

> My apologies if my raising of this was seen as trolling. I
> was not attempting too suggest which was the best for all
> situations, simply that Nico's solution is viable for many
> projects these days.
>
> Obviously if you are going to continue to use old *nix based
> scripts that remain vulnerable after all these years then
> of course you must work-around such limitations, for which
> the features of svn are very convenient.

Well, that is not "limitation" but a de-facto situation.

On Unix, a script with CR-LF is really unlikely to work, either with Bash, Perl or others...
The same way a .bat script on Windows fails if LF.

For me, this SVN feature is not for "work-around" but to
support multi-platform development "the right way".
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.file-portability.html

And what about text file encoding ??
That is so easy to find two Linux boxes in UTF-8 and latin-1 encodings even in the same company in Europe,
it is already a nightmare.
We really have to "work-around" non-ANSI-compliant developers languages !

As Subversion does not provide a proper encoding support, developers must be fixed
so they do not write comments in non-ANSI characters with their non-US keyboards ;)

In fact, I could not wait and I use pre-commit hooks to validate text content
compliance with project policy concerning charset/encodings.

So the end-of-line problem is really simple compared to encodings.
And with developpers all around the world working on the same codebase,
it is difficult to check/enforce everyone use the "right tool"
with the proper configuration on any platform.

-- 
Yves Martin