----- "Geoff Worboys" <ge...@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
