On Tue, Dec 11, 2001 at 11:47:49AM -0600, Karl Fogel wrote:
> Billy Tanksley <btanksley@hifn.com> writes:
> > Okay, here's a problem: if we're using patch, we'll have to know what the
> > correct line endings are. Patch won't preserve them; it'll either use
> > system-dependant or all-Unix line endings. We'll have to convert when patch
> > is finished.
> >
> > An ideal patching program would use 'record endings' which were variable --
> > so you could patch a file with some CRs, some LFs, and some CRLFs (and even
> > some commas), and all would go well. But this isn't how the traditional
> > patch program works, and of course there's no room for this in the diff
> > format.
>
> Yes -- this is a problem we will need to solve independently of
> newline conversion (imagine you have a text file with newline
> conversion turned off, and it gets patched).
A couple of other problems come to mind:
Some Unix text editors do not handle DOS line endings gracefully.
nvi, for instance, will show you a ^M on the end of each line; it'll
be treated as part of the line (e.g. A will start inserting after the
^M); and it will happily write out the file with mixed line endings
when you're done.
GCC through 2.95.x doesn't understand anything other than Unix line
endings. 3.0 and up do understand DOS and Mac line endings, but if
you feed it a file with mixed line endings it's liable to get the line
numbers confused. (Come to think of it, so is just about everything
else. A file with mixed line endings does not have well-defined line
boundaries, to a program that is conscious of multiple forms.)
On the other hand, I don't like the idea of having SVN do _anything_
to my file that I didn't explicitly ask for. So I'm +1 on having a
line ending canonicalization option, and -1 on having it on by
default.
zw
---------------------------------------------------------------------
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