| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The most common use for CVS is to store text files. With text files, CVS can merge revisions, display the differences between revisions in a human-visible fashion, and other such operations. However, if you are willing to give up a few of these abilities, CVS can store binary files. For example, one might store a web site in CVS including both text files and binary images.
| 9.1 The issues with binary files | More details on issues with binary files | |
| 9.2 How to store binary files | How to store them |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 cvs
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 section Multiple developers). The second is when one merges explicitly with the `update -j' command (see section Branching and merging).
In the case of te