While the need to manage binary files may seem obvious if the files that you customarily work with are binary, putting them into version control does present some additional issues.
One basic function of version control is to show the
differences between two revisions. For example, if
someone else checked in a new version of a file, you
may wish to look at what they changed and determine
whether their changes are good. For text files,
CVS provides this functionality via the
diff command. For binary files, it may be possible to
extract the two revisions and then compare them with a
tool external to CVS (for example, word processing
software often has such a feature). If there is no
such tool, one must track changes via other mechanisms,
such as urging people to write good log messages, and
hoping that the changes they actually made were the
changes that they intended to make.
Another ability of a version control system is the ability to merge two revisions. For CVS this happens in two contexts. The first is when users make changes in separate working directories (see Multiple developers). The second is when one merges explicitly with the ‘update -j’ command (see Branching and merging).
In the case of text files, CVS can merge changes made independently, and signal a conflict if the changes conflict. With binary files, the best that CVS can do is present the two different copies of the file, and leave it to the user to resolve the conflict. The user may choose one copy or the other, or may run an external merge tool which knows about that particular file format, if one exists. Note that having the user merge relies primarily on the user to not accidentally omit some changes, and thus is potentially error prone.
If this process is thought to be undesirable, the best choice may be to avoid merging. To avoid the merges that result from separate working directories, see the discussion of reserved checkouts (file locking) in Multiple developers. To avoid the merges resulting from branches, restrict use of branches.