Proposal to fix CVS binary file implementation

[David L. Martin]

CVS'ers,

 

A binary file is a binary file.  Period.  It can contain any sequence of characters, the encoding and interpretation of which is solely understood by the application that created it.  CVS should do nothing in terms of keyword expansion or End Of Line conversion to modify a binary file.  Yet, because of the behavior referenced below, CVS does modify binary files under certain conditions, namely when attempting to perform a merge while disabling keyword expansion, where the *intent* is to apply -kk only to non-binary files.  Merging would work much better if CVS did not override the local keyword expansion mode for an archive that has been defined to contain binary data (-kb), regardless of what the user requested on the command line (e.g. cvs update -kk).  If the user wants to change the "binary-ness" of a file, this should be performed using cvs admin, but never "on-the-fly" based on options to checkout or update.

 

*****
http://cvshome.org/docs/manual/cvs_5.html#SEC64
"There is, however, one major caveat with using `-kk' on merges. Namely, it overrides whatever keyword expansion mode CVS would normally have used. In particular, this is a problem if the mode had been `-kb' for a binary file. Therefore, if your repository contains binary files, you will need to deal with the conflicts rather than using `-kk'"
*****

 

We need to decouple, in concept and in implementation, "binary" and "keyword expansion mode".  The binary nature of a file (which mandates no EOL translation and no keyword substitution) is an immutable attribute of the file which must always take precedence.  It should not be adjustable using checkout or update.  I cannot think of any circumstance where a binary file would ever need to be transiently defined as anything different.

 

My CVS Christmas wish:  Can we (CVS users/developers) come to a consensus to devise a fix to allow keyword expansion, binary files, and merging to work harmoniously "out of the box" (e.g. in a way that will make it into the main CVS code line?)  I believe we have a lot of developers and CVS administrators implementing a variety of workarounds.  I know this has been brought up several times in the past and has resulted in many a flame war.

 

A frequent argument against changing is that CVS was not designed to handle binary files.  This may be true, but the introduction of the -kb option tends to prove a willingness and desire in the CVS development and user community to accomodate binary files.  Many (myself included) have implemented procedures or written scripts to effectively exclude binary files from the merge operation, or to perform some pre- or post-processing on the files or archives used in the merge to correct the problems encountered using cvs update -kk.  Others may construct their repositories so that binary files live in their own directories in a sort of "binary prison", apart from the ASCII source files, so that the binary files may be more easily excluded from merge operations.  I don't think this is a good solution because CVS then dictates repository structure, even when cohesive functional grouping may dictate that ASCII and binary files should coexist in the same directory.

 

I think it's time for us to close the loop and implement binary file support in a manner which is more merge-friendly, one which accomodates both ASCII and binary files in the same merge operation (where merging of binary files results in *copies* being made and no actual merging - with no binary file keyword expansion or EOL translation).

 

Here's what I would propose (and I underscore *propose*):
1)  Maintain the current keyword expansion modes, as persisted in the archive or in the local working area in the Entries file as "kv, kvl, k, o, b, or v";
AND
2)  EITHER:
     a) Provide a new command line keyword expansion option "-km" on cvs update and cvs checkout to support merging.  The effect would be that the working area local keyword substitution mode would overridden to "k" for all but binary files, which would remain "b".
     OR
     b) Change the current behavior of update and checkout to never override the archive-stored default keyword substitution mode for binary files.

 

Any comments?  Wait, let me put on my Kevlar heat-resistant suit first...

 

David Martin