Table of Contents
The most common use for cvsnt is to store text files. With text files, cvsnt 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, cvsnt can store binary files. For example, one might store a web site in cvsnt including both text files and binary images.
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, cvsnt 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 cvsnt (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 cvsnt this happens in two contexts. The first is when users make changes in separate working directories (Chapter 11, Multiple developers). The second is when one merges explicitly with the update -j command (Chapter 6, Branching and merging).
In the case of text files, cvsnt can merge changes made independently, and signal a conflict if the changes conflict. With binary files, the best that cvsnt 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 Chapter 11, Multiple developers. To avoid the merges resulting from branches, restrict use of branches.