On May 30, 2011, at 22:58, Nico Kadel-Garcia wrote:
> On Mon, May 30, 2011 at 2:43 PM, Ryan Schmidt wrote:
>>
>> On May 30, 2011, at 11:26, Nico Kadel-Garcia wrote:
>>
>>> There's a potential risk with the approach: CygWin uses UNIX
>>> compatible end-of-line characters. TortoiseSVN, and other Windows
>>> based clients, use Windows end-of-line. The result can be *CHAOS* if
>>> you typically set source files, such as .html, .php, or .c, .sh, or
>>> .pl files, to use "svn:eol-stile", or expect files to be automatically
>>> set in Windows or UNIX style as you switch from programming from a
>>> source repository in Windows, and one in CygWin.
>>
>> *Not* setting svn:eol-style to some value will lead to chaos, as you use different editors with different ideas of what a line ending is, and you start getting files with inconsistent line endings. *Setting* svn:eol-style to some value should prevent said chaos, by
>
> Then the editor, or practice of the developer, is fractured. In this
> day of shared network based file systems and replication of developed
> components via NFS, CIFS, SCP, and HTTP download, it is a dangerous
> presumption that the EOL can be reset on a client system by client
> system basis. CygWin is the best example of this: files checked out
> and replicated with the CygWin based SVN will have one EOL for such
> "clever" approaches, checked out with TortoiseSVN will have another.
> The configured EOL approach to this which Subversion supports, as an
> option, is hideously dangerous in such environments.
>
> There are a few cases where OS specific EOL is useful, but they're
> rare. Markup languages have a standard EOL written in: so does C,
> Perl, Ruby, Java, and all the other programming languages. It's only
> really useful in poorly implemented configuration files which weren't
> written with such a standard, and certain forms of stored text files,
> and most editors and display tools can use those just fine. (Wordpad
> versus Notepad, for example, works well for the Windows users.)
>
> I've actually seen this play out in C++ and Java and PHP and HTML in
> the last.... 5 years. People checking out repositories on one OS to a
> shared network directory, such as their Windows box with TortoiseSVN
> for the superior interface, were alarmed to find the code mangled when
> they did work with C, or replicated files and tried to import them
> elsewhere *without* the same EOL settings. Chaos ensued repeatedly.
As far as I can tell, everything you wrote applies only to the case where you set svn:eol-style to native. Re-read my previous message. In it, I agree that setting svn:eol-style to native can cause certain problems, when your working copy crosses platform boundaries. However, NOT setting svn:eol-style to ANY value only invites the problem of getting files with inconsistent line endings committed to the repository, and THAT is something I would certainly want to avoid (and that can be achieved by setting svn:eol-style of text files to any value that pleases you: LF, CRLF, or native).
Received on 2011-05-31 09:09:13 CEST