[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 21:21:04 CET

> To: Roman Neuhauser <neuhauser@mobil.cz>
> Cc: dev@subversion.tigris.org, Karl Fogel <kfogel@newton.ch.collab.net>
> From: cmpilato@collab.net
> Date: 11 Dec 2001 13:44:18 -0600
> Subject: Re: Poll: do we really need newline conversion?
>
> Roman Neuhauser <neuhauser@mobil.cz> writes:
>
> > 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...
>
> You do recall correctly (I used UltraEdit all the time). However,
> that's a problem with the how the UltraEdit tool was handled on the
> source code, not how Subversion handled the versioning/retrieval of
> such.

    My point was that ignoring the EOL problem completely can lead to
    worse problems (from the user POV, I know nil about coding it) than
    it tries to avoid.
    No EOL conversion for "text" files would mean SVN is just the thing
    everybody hates in CVS, just upside down (I'm trying to say that no
    EOL conversion would just like CVS trashing users binary files).

> > > * 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.
>
> You're absolutely correct. And thankfully, Subversion has no support
> for commit emails, either. We do, however, have tools (external to
> Subversion, mind you) and a good API that can assemble a commit mail
> and dispatch it. Likewise, you could have a tool (again, external to
> Subversion) that converts your line-endings back and forth for you.

    If SVN has an "API that can assemble a commit mail and dispatch it",
    then it has _support_ for commit mails. Or I don't know what support
    is. Mind you, I don't care a dime whether the EOL conversion is done
    by the svn client, server, or 10 lines of a shell script that you
    plug into either of those two.[1] I just beg for EOL conversion to be
    an option.

    [1] I know that it _does_ matter if the conversion happens
    pre-commit, post-checkout, or whatever. I just don't want to deal
    with details now.
 

-- 
FreeBSD 4.4-STABLE
9:12PM up 49 days, 7:55, 13 users, load averages: 0.04, 0.04, 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.