> To: Roman Neuhauser <firstname.lastname@example.org>
> Cc: email@example.com, Karl Fogel <firstname.lastname@example.org>
> From: email@example.com
> Date: 11 Dec 2001 13:44:18 -0600
> Subject: Re: Poll: do we really need newline conversion?
> Roman Neuhauser <firstname.lastname@example.org> 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
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. I just beg for EOL conversion to be
 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.
9:12PM up 49 days, 7:55, 13 users, load averages: 0.04, 0.04, 0.05
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 21 14:36:52 2006