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

RE: Poll: do we really need newline conversion?

From: Barry Scott <barry.alan.scott_at_ntlworld.com>
Date: 2001-12-11 21:52:53 CET

Yes you do: mandatory feature.

I work between Unix and Win32. Tools on Unix choke on CR/LF
* /bin/sh
* g++
  try:
        #define fred \
                12
        and see A syntax error.
* hp C++
* python 2.1.1
 
Tools on Win32 choke on LF, notepad for example will not show a readme.txt,
you have noticed the .dsp,.dsw problems. (At least the MSVC compile is happy
with LF files).

What is the current state of play in the Mac world? They use CR and choked on
LF or CRLF text files in the past.

We use the SourceSafe EOL conversion feature when working between Unix
and Win32 which solves these problems.

I cannot image using a SCM tools without EOL conversion support in a multi
OS world.

        BArry

-----Original Message-----
From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
Sent: 11 December 2001 17:21
To: dev@subversion.tigris.org
Subject: Poll: do we really need newline conversion?

Recently, some people posted asking whether Subversion should even
bother to perform newline conversion.

On pondering the question, I have to admit they have a point. :-)

   * Modern text editors handle all newline styles transparently.
     It's true that Windows Notepad doesn't work with LF-only files,
     but then again, Notepad also doesn't do files larger than 32kb,
     so I feel pretty comfortable not worrying about Notepad.

   * Although we've had some problems with the line endings in
     .dsp/.dsw files, solving those particular problems certainly
     didn't require Subversion to do newline conversion; they were
     more a matter of pilot error.

   * Mike Pilato argues (convincingly, IMHO) that newline conversion
     is way outside the scope of a version control system anyway, that
     it's just a weird bit of creeping featurism that doesn't even
     provide something terribly useful anymore, and has the potential
     to damage data (since it's a departure from faithfully versioning
     whatever people checked in).

Frankly, I'm thinking we shouldn't bother. Why spend time on a
feature that a) people rarely need these days and b) has the potential
to do unexpected things to people's data?

Would like to know what other people think...

(Note that this question is independent of keyword substitution, and
also doesn't affect our need to recognize text vs binary files --
we'll always need that differentiation, so we know when we can use
patch to do textual merges.)

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:52 2006

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.