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 <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Antony Paul <[EMAIL PROTECTED]> 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----- > _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
