info-cvs
[Top][All Lists]
Advanced

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

Re: Ignoring whitespace and CR/LF when checking into repository


From: Antony Paul
Subject: Re: Ignoring whitespace and CR/LF when checking into repository
Date: Fri, 19 Nov 2004 18:06:03 +0530

Does making files binary using -kb compromises any other
functionality. Some developers want CVS to merge changes
automatically. If the file is treated as binary will it merge ?.

Does any one have an example of a commitinfo filter which can identify
ASCII files ?

Using commitinfo does requires a server ?.

rgds
Antony Paul


On Thu, 18 Nov 2004 06:59:13 -0800, Mark D. Baushke <address@hidden> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Antony Paul <address@hidden> writes:
> 
> > These make me ask more questions.
> >
> > What is the default line ending character for ASCII files store in a
> > repository ?.
> 
> Files in the repository are in RCS format and are able to store both
> ASCII and binary verions of files... you should probably consider these
> files to be 'binary' rather than ASCII files if you are moving them
> around between systems.
> 
> > Is this varies from OS to OS ?.
> 
> Yes.
> 
> On UNIX boxes, a "text file" ends with a line-feed (LF == 0x0a)
> character. This includes the MacOS X operating system.
> 
> On DOS boxes, a "text file" ends with two carriage-return (CR == 0x0d)
> control-j (0x0a).
> 
> On old Apple boxes, a "text file" ends with carriage-return (CR == 0x0d).
> 
> On EBCDIC boxes, a "text file" may have a number of different
> representations, but many common file formats do not have a line ending
> character and instead mantain per-line length records for the file.
> 
> A "binary file" is considered opaque and no translations are done.
> 
> On both UNIX and Windows, many tools are bright enough to maintain the
> existing line-endings of a given file. However, this is not universally
> true.
> 
> If you want the rest of the possible endings used on other machines out
> there, you would need to visit your favorite search engine to look for
> the information.
> 
> > Does CVS client or server is supposed to perform the line ending
> > character conversion when a ASCII file is committed ?
> 
> If the file is -kb, then no transformations are done and all files are
> handled as if they had opaque contents.
> 
> If the file is otherwise, then line-ending tranformations are handled
> between the client and server with the client telling the server about
> line breaks.
> 
> > Now the root cause of my problem is that when checked in by windows
> > developers using Eclipse it have CR/LF as line ending character and it
> > is stored as it is. Now I want that all files must be stored in Unix
> > format.
> 
> I am not sure about Eclipse on windows, I have heard that the Cygwin
> environment has a preference setting to specify how the tools should
> behave with regard to generation of CRLF or LF line endings.
> 
>         -- Mark
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (FreeBSD)
> 
> iD8DBQFBnLjB3x41pRYZE/gRAj/XAKCqvzIE5V5sv8tZCzbHywbUHLwhbACgzl6j
> Z/+8A7ZflqzjvvGL8sPIrO0=
> =21Lo
> -----END PGP SIGNATURE-----
>




reply via email to

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