|
From: | David L. Martin |
Subject: | Proposal to fix CVS binary file implementation |
Date: | Thu, 21 Dec 2000 00:22:41 -0600 |
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
|
[Prev in Thread] | Current Thread | [Next in Thread] |