[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 |
Hi,
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
files.
Christian
- Re: CVS and unicode, (continued)
- Re: CVS and unicode, Larry Jones, 2005/09/12
- Re: CVS and unicode, Christian Hujer, 2005/09/12
- Re: CVS and unicode, Russ Sherk, 2005/09/12
- Re: CVS and unicode, Spiro Trikaliotis, 2005/09/13
- Re: CVS and unicode, Jim Hyslop, 2005/09/12
- RE: CVS and unicode, Dave Korn, 2005/09/12
- Re: CVS and unicode, Spiro Trikaliotis, 2005/09/11
- Re: CVS and unicode,
Christian Hujer <=
- Re: CVS and unicode, Jim Hyslop, 2005/09/12
- Re: CVS and unicode, Christian Hujer, 2005/09/12
- Re: CVS and unicode, Jim Hyslop, 2005/09/12
- Message not available
- Re: CVS and unicode, Pierre Asselin, 2005/09/11
- Re: CVS and unicode, Larry Jones, 2005/09/12
- Re: CVS and unicode, Derek Price, 2005/09/12
- Re: CVS and unicode, Christian Hujer, 2005/09/12
RE: CVS and unicode, Arthur Barrett, 2005/09/05