| [ < ] | [ > ] | [ << ] | [ 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 10. Multiple developers). The second is when one merges explicitly with the `update -j' command (see section 5. 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
Whenever you commit a file you specify a log message.
To look through the log messages which have been
specified for every revision which has been committed,
use the cvs log command (see section A.13 log--Print out log information for files).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can use the history file (see section C.11 The history file) to
log various CVS actions. To retrieve the
information from the history file, use the cvs
history command (see section A.11 history--Show status of files and users).
Note: you can control what is logged to this file by using the `LogHistory' keyword in the `CVSROOT/config' file (see section C.13 The CVSROOT/config configuration file).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can customize CVS to log various kinds of
actions, in whatever manner you choose. These
mechanisms operate by executing a script at various
times. The script might append a message to a file
listing the information and the programmer who created
it, or send mail to a group of developers, or, perhaps,
post a message to a particular newsgroup. To log
commits, use the `loginfo' file (see section C.7 Loginfo).
To log commits, checkouts, exports, and tags,
respectively, you can also use the `-i',
`-o', `-e', and `-t' options in the
modules file. For a more flexible way of giving
notifications to various users, which requires less in
the way of keeping centralized scripts up to date, use
the cvs watch add command (see section 10.6.2 Telling CVS to notify you); this command is useful even if you are not
using cvs watch on.
The `taginfo' file defines programs to execute
when someone executes a tag or rtag
command. The `taginfo' file has the standard form
for administrative files (see section C. Reference manual for Administrative files), where each line is a regular expression
followed by a command to execute. The arguments passed
to the command are, in order, the tagname,
operation (add for tag,
mov for tag -F, and del for
tag -d), repository, and