So, in the interests of keeping the Subversion handbook current and reliable, what is the present advice regarding svn:eol-style?
Richard ----- Original Message ----- From: Nico Kadel-Garcia Sent: 01/25/12 02:57 PM To: Les Mikesell Subject: Re: Compatible with Microsoft Office and Internet Explorer On Tue, Jan 24, 2012 at 9:38 PM, Les Mikesell <lesmikes...@gmail.com> wrote: > On Tue, Jan 24, 2012 at 8:17 PM, Nico Kadel-Garcia <nka...@gmail.com> wrote: >> On Tue, Jan 24, 2012 at 8:44 PM, Richard Cavell <richardcav...@mail.com> wrote: >>> What do you do if you're accessing the same filesystem from both Windows and >>> UNIX? What line-ending method do you use for text files, and what do you >>> put for svn:eol-style? >>> >>> Richard >> >> I rely extensively on the default of *no* setting, referred to in >> Subversion as not setting or blocking the "svn:eol" property. This >> treats line endings as effectively binary data, preserved identically >> no matter which platform you check out files on. If you need to work >> with Windows line endings for source code on one system, and UNIX line >> endings for source code on another, that's a locak system problem, not >> properly a source control problem. > > No, it is a transport problem, and if you use a source control system > to transport text it should make it text as expected on each client. This is one of those cases where I really disagree with this dangerous model. Expecting on the fly translation, by the source control system, of the format of the files leads to very confusing and awkward results, for which I've listed examples. Like expecting the document viewer to automatically translate date formats of enclosed documents, it can get *extremely* confusing. >> I'm afraid I've had real adventures when someone insisted on working >> with TortoiseSVN with "svn:eol" set to "native", and thenm trying to >> build perl scripts and Java source code on both Windows and Linux >> systems in the same home directory. This led to madness.... > > But the madness comes from not converting to the expected text form. > If you bypass that on purpose, do you preprocess every text file > before use on each system or restrict access to a small set of tools > that might work in spite of this input? I respectfull y disagreee, with the messed up scars to match. A source repository should be just that, a source repository. The checked out source code that *appears* to work with both the text-based CygWin client or a Linux client, and a Windows client, fails not becuase the compilers or scripting languages can't handle the code, but because the "svn:eol" has switched the content of the file at checkout time, and the other client has no way to detect that it needs to be switched back on upload. So a file that you check out in Windows, using "svn:eol native", will be seen by a CygWin or Linux client as having its EOL modified and will be reported as altered and potentially committed with the line ending changes. Chaos ensues, even round-robin cases where ^H gets added cyclically to the same files on every automated checkin of a build procedure. (Welcome to Java code that is supposed to be "cross-platform" and automated build procedures with "Cruise Control" software. Been there, done that , had to replace the repo and put in pre-commit hooks to block the use of svn:eol.
