<div id="Binary-why"></div>
<div class="header">
<p>
Next: [[cvs: How to store binary files#How to store binary files|Binary howto]], Up: [[cvs: Handling binary files#Handling binary files|Binary files]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>

----

<div id="The-issues-with-binary-files"></div>
=== The issues with binary files ===

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,
<small>CVS</small> provides this functionality via the <code>cvs
diff</code> command.  For binary files, it may be possible to
extract the two revisions and then compare them with a
tool external to <small>CVS</small> (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 <small>CVS</small> this
happens in two contexts.  The first is when users make
changes in separate working directories
(see [[cvs: Multiple developers#Multiple developers|Multiple developers]]).  The second is when one
merges explicitly with the &lsquo;<code>update -j</code>&rsquo; command
(see [[cvs: Branching and merging#Branching and merging|Branching and merging]]).

In the case of text
files, <small>CVS</small> can merge changes made independently,
and signal a conflict if the changes conflict.  With
binary files, the best that <small>CVS</small> 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
[[cvs: Multiple developers#Multiple developers|Multiple developers]].  To avoid the merges
resulting from branches, restrict use of branches.


----

<div class="header">
<p>
Next: [[cvs: How to store binary files#How to store binary files|Binary howto]], Up: [[cvs: Handling binary files#Handling binary files|Binary files]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>
This document was generated on <i>a sunny day</i> using [http://www.nongnu.org/texi2html/ <i>texi2html</i>].
