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: Sat, 10 Sep 2005 17:52:09 +0200
User-agent: KMail/1.7.1

Hi,

Am Samstag, 10. September 2005 16:04 schrieb Spiro Trikaliotis:
> Hello Christian,
>
> * On Sat, Sep 10, 2005 at 12:38:19PM +0200 Christian Hujer wrote:
> > Currently, CVS has extremely tolerant behaviour regarding binary files
> > which were accidently added as text files. As long as they do not contain
> > keywords (like $Id...$), they are extremely likely to still be handled
> > conveniently.
>
> This is true for Unix based systems, but not for systems where CR/LF is
> the usual line ending. Checking in a binary file from a Windows system,
> you have very good chances to break it if there is a CR/LF anywhere
> inside of it.
>
> For non-CR/LF machines, checking in binary files without -kb does
> not do any harm even if there are keywords ($Id$, for example) inside of
> it. CVS checks them in "as-is" and only expands the keywords on
> checkout. Thus, if you forgot doing the -kb on checkin, just set the
> state afterwards with cvs admin and check the file out again.
>
> As told, this is NOT true for CR/LF based systems.
It's even true for CRLF. The CRLF byte sequences are:
ASCII: 0x0D 0x0A.
UTF-8: 0x0D 0x0A.
UTF-16 LE: 0x0D 0x00 0x0A 0x00.
UTF-16 BE: 0x00 0x0D 0x00 0x0A.

CVS will not interfer with any of these.
UTF-16LE sequence will be split within the LF char. But since the next line 
will be split at exactly the same point, this is not a problem for line 
diffs.

Also, CVS behaves very fine when using CR/LF (though I regard CR/LF being 
deprecated for various other reasons), independently of the encoding (at 
least those encodings discussed here).

-- 
Christian Hujer
ITCQIS GmbH
E-Mail: address@hidden
WWW: http://www.itcqis.com/




reply via email to

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