[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: Roman Neuhauser <neuhauser_at_mobil.cz>
Date: 2001-12-11 20:15:30 CET

> To: dev@subversion.tigris.org
> From: Karl Fogel <kfogel@newton.ch.collab.net>
> Date: 11 Dec 2001 11:20:37 -0600
> 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.

    I don't think the issue is notepad displaying LF files as a single
    line with some strange hollow squares instead of newlines. But no
    EOL conversion could bite you in quite a few situations... IIRC
    UltraEdit can be set up to display LF files properly, and convert
    them to CRLF when you write them out. Check out, modify a single
    line, and commit. Oops, the diff is somewhat longer than expected...
 
> * 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.

    .ds[pw] files shouldn't undergo EOL conversion, but should be
    "diffable", IMO.
 
> * 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).
 
    Well, this is a matter of taste. I could agree that EOL conversion
    is beyond the scope of a RCS, but then I could also argue that so is
    the "commit email" feature, for example. It has nothing to do with
    revision control after all.

> 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?

    I think that you should discriminate text files and binary files,
    like images.
    I sincerely hate the bug in CVS that causes it to EOL-convert, and
    expand keywords in all files by default, and it made me really happy
    to read that the plan was to have both of these of in SVN (in the
    Design Notes).
    But I think that having these two features off by default,
    independent of each other, and maybe even independent of whether the
    file is "text" or "binary" would be the perfect solution.
 
    So... -0.5.

-- 
FreeBSD 4.4-STABLE
8:01PM up 49 days, 6:44, 13 users, load averages: 0.17, 0.10, 0.05
---------------------------------------------------------------------
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.