On Tue, Jan 24, 2012 at 10:57 PM, Nico Kadel-Garcia <nka...@gmail.com> wrote:
>>>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.
No, your examples were where you deliberately circumvented the
conversion in the transport. The fact that text is different on
different systems isn't really something you can disagree with. I
don't like it any more than you do, but that's just the way it is -
something decided back in a different century.
>>> 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.
No, your scars came from _not_ letting the conversion work correctly.
You let different OS's see it without having gone through the
appropriate transport.
> A source
> repository should be just that, a source repository.
Something that handles text needs to handle text in the native OS
form. Something that transports text across platforms needs to
deliver native text to each. You can't just pretend that text is not
different on different platforms even if you wish that were true.
> 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.
Cygwin is a weird beast. Use it only if you understand and want what it does.
> 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.
Of course, if you use a method of getting a text file to a different
OS in a way that doesn't perform the needed conversion, it won't work.
If it hurts, don't do that.
> 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.
Errr, what? Why would an automated build be checking in/out on the
wrong OS? Doesn't that system let each target system do its own
checkouts in cross platform builds? I'm pretty sure we have people
doing that with Jenkins all the time.
> Been there, done that, had to replace the repo and put in pre-commit
> hooks to block the use of svn:eol.
But you didn't answer my question above. Many/most tools simply will
not work without conversion. Since you don't use the painless
approach of having everything done automatically, what do you do
instead? Do you always use your own conversion tool before letting
anything else touch the text, or do you restrict access to a small set
that you know will work in spite of the non-native text format. Or
do you really only use the text under one OS and just occasionally do
some editing on a different platform where you can get by with the
wrong endings?
--
Les Mikesell
lesmikes...@gmail.com
