info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS and unicode


From: Christian Hujer
Subject: Re: CVS and unicode
Date: Mon, 12 Sep 2005 21:04:42 +0200
User-agent: KMail/1.7.1

Hi,

Am Montag, 12. September 2005 05:57 schrieb Jim Hyslop:
> Christian Hujer wrote:
> > This is not the point of the program but of the file specification.
> > If a file specification says "This is a text file. Line endings always
> > have to be LF, regardless of the operating system."
>
> In that case, the specification is broken: line endings are defined by
> the operating system, not by a file specification. Suppose I defined a
> file specification as: "This is a text file. Line endings always have to
> be ASCII 0x7f, regardless of the operating system."
Good point.

Yet there's some difference. 0x0A and 0x0D are in wide use, while 0x7f isn't 
(especially not in the sense of line ending).

> > I have to be the ruler over line endings and encodings, because this is
> > the only way I can make sure that every single byte in the file is the
> > way I want. For me this is also true in the context of version controlled
> > text files.
>
> This seems to be a case of the tail wagging the dog. You have cited one
> particular example where automatic line ending conversion is a problem.
> Should we invalidate thousands of other use-cases where automated line
> ending conversion is not only desirable, but the correct course of action?
I do not see any course where line ending conversion is correct course of 
action.
I'd even expect a CR/LF file checked in on Windows to retain it's CR/LF 
endings when checked into a repository (no matter wether UNIX or Windows), 
and I'd expect the file to still contain CR/LFs when I check it out on UNIX. 
Which will be the case if the file contains CR/LF in the repository.

Christian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]