[Top][All Lists]

[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: Sun, 11 Sep 2005 20:52:48 +0200
User-agent: KMail/1.7.1


Am Sonntag, 11. September 2005 16:51 schrieb Spiro Trikaliotis:
> Hello Christian,
> > And afair cvs on Cygwin does not perform any CR/LF conversion at all.
> Hm, well... I'm not sure if it is the CVS client on cygwin or cygwin
> itself (if installed to utilize CR/LF endings), but on cygwin, this
> conversion takes place.
Well not for me, but...

> Although CR/LF vs. LF is a problem in itself, I would not recommend
> using cygwin and cvs in "LF only" mode. I have done so before, and I
> encountered many problems this way, most often these were some garbled
> output. It just does not work as it should.
and I would recommend nothing but using Cygwin with LF only mode.

> Furthermore, the "natural" ending on Windows machines is CR/LF, if you
> like it or not.
Well, it is, and I don't like it :)

> It does not make much sense to use LF only and be 
> restricted to some specific editors and other programs which can handle
> the LF only. Many programs will convert LF to CR/LF (or, even worse,
> will behave erroneously), thus, this is not a good alternative.
Some specific editors ... well, I think the number of windows editors able of 
handling LF outnumbers by far those that aren't. CR/LF only editors 
definitely are a small minority.

> BTW: Personally, I would consider a Windows program which cannot handle
> CR/LF as broken. It is like I would tell you "I can speak chinese" but
> not being able to understand or write even one sentence in it.
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." an automatic conversion behaviour 
breaks the file specification.

I'm on the point of saying that programs must never ever do any conversions 
unless explicitely told to do such a conversion. If the file is LF, I expect 
it to be checked out and checked in with LF. If the file is CR/LF, I expect 
it to be checked out and checked in with CR/LF. With -kb, I tell CVS to not 
perform keyword substitution. So without, I tell CVS to use its standard 
behaviour, but I'm not telling CVS to convert LF to CR/LF or the otherway 
round so it must not do so.

And if this originates from operating systems that treat text files 
differently from binary files (like Windows), I expect tools to open these 
text files in binary mode as well, to avoid such problems.

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 


reply via email to

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