[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: eol style differences

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-03-12 21:46:57 CET

Branko ÄŒibej <brane@xbc.nu> writes:

> >Even if there are (Windows?) editors that, say, accept LF line endings
> >and write CRLF line endings, is that a big problem? After the first
> >checkin, the one that translates the file, subsequent checkins aren't
> >really a problem. Or are we attempting to handle scenarios where
> >there are two broken editors, one doing LF-to-CRLF and the other doing
> >CRLF-to-LF? How likely is that?
> >
> In any environment where you're editing on more than one platform.

No, editing on more than one platform is not enough. I've done that.
You also need *broken editors* on more than one platform. How likely
is that?

> I expect most Unix editors write just \n, again regardless of the
> prevailing style.

I've used half-a-dozen flavours of Unix and I've never had an editor
do that, unless I asked it to do it.

> The result is a mess.
>
> Not to mention many, many Unix C compilers that will turn a blind eye to
> line continuation if they happen to see backslash-CR-LF.

That could be a problem. So my next question applies: how often does
it occur in real-life? How often does a developer use a brain-damaged
editor in a mixed Unix/Windows C development environment?

> >Do we have any real-life examples where svn:eol-style fixes a problem?
> >Why should it be Subversion's job to solve this problem anyway?
> >
> Because that's what people expect of a cross-platform version management
> tool. Sad, but true.

Will they notice if we don't do it? Perhaps we just need to "educate"
them?

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 12 21:47:43 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.