On Tue, Jan 24, 2012 at 9:38 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On Tue, Jan 24, 2012 at 8:17 PM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
>> On Tue, Jan 24, 2012 at 8:44 PM, Richard Cavell <richardcavell_at_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 respectfully 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.
Received on 2012-01-25 05:58:10 CET