CVS and binary files

There are various problems with CVS's handling of binary files, especially on Windows. In the past there have been quite a few known bugs (many of which are fixed), but the known features are kind of problematical too :-(.

• This patch provides for a -kbauto option to enable automatic detection of binary files.
• If we don't want to automatically detect binary files with the "would a text checkin corrupt it" algorithm, would it be feasible to at least use some kind of checksum or something so we know after the fact if there was corruption? Or would that be just as hard as determining binary-ness?
• The fact that the -k setting is per-file rather than per-revision means that it is impossible to correctly handle the case in which a file with a certain name is binary for some revisions, and text for others.

Line Endings in Text Files

OK, this is sort of a text file issue more than a binary file issue, but the two are related.

There should be a way to use text files with a variety of line endings, rather than having it hardcoded based on the operating system. VMS is the most obvious case, where a checkout could both use the desired line endings and set the file attributes correctly. Another topical example is that Windows users seem to be split between those who want CRLF (Developer Studio, &c) and those who want LF-only (perl, maybe some cygwin folk). There should be some way to configure different choices here (orthogonal to -k, because one might want to combine any of these choices with -ko or -kkv or whatever). Once we get the framework in place, adding CR-only (Macintosh) and what have you shouldn't be too hard. In a way this is bad, in the sense that if text files are configured for LF-only, then failure to specify -ko/-kb for binary files would still be a problem, but a subtler one. This could be helped somewhat with documentation suggesting that people use wrappers to default all files to "-ko". As for listing the possibilities (CRLF, LF-only, CR-only, &c), might see if MIME or any such standards have any relevant concepts (Content-transfer-encoding or whatever, although not sure this one fits).

Another way of thinking of "LF-only on non-unix platforms" is that CVS does not mess with the line endings. That is, one might use CRLF on Unix, or what-not. This creates its own set of potential problems and confusions (especially if you consider things like log messages, as well as the CVS-controlled files themselves).

There is a version of CVS with a -B option to enable this kind of operation ("all files are binary" or "LF-only" or however you want to think of it) at elf's site. If you like the idea, give this a try. Figure out whether it is really what you want (both in general and in detail). Report back to the community (for example, the info-cvs mailing list or comp.software.config-mgmt newsgroup). There are a lot of issues here which need to be figured out (documentation and compatibility, for example).

Obsolete patches

There is a known bug in CVS 1.10 through 1.10.4: if you run "cvs add -kb" on a file which previously existed as a text file, (the case where CVS prints "re-adding file file1 (in place of dead revision 1.2)"), the -kb will not take. The work around is to use "cvs admin -kb". This is "binfiles3" in the CVS testsuite.