RE: How well does CVS handle other types of data?

[Ralph Mack]

> Note also that CVS uses RCS files.  RCS uses diff and diff3.  All
> these things together imply that CVS only handles text files.  Q.E.D.

Not necessarily. RCS uses diff and diff3 in specific operations. It also
does a lot of other things, like keeping track of what content belongs in
each revision. To support binary files it is only necessary to prevent the
performance of those RCS operations which perform diff and diff3 on those
files in ways that are harmful to them.

> You already have a build system (since of course CVS is not a build
> system).  It already deals with software configuration components that
> are not source files stored in CVS.

It does? My general expectation is that I can do a single command to
checkout the entire base of required files, mergable or not, from an
appropriate label. I can then perform another single command to execute
the makefile or antfile stored under that label to perform operations on
files stored under that label to produce a set of artifacts. If I have
set the label properly and included all relevant files, this should
repeatably and reliably produce artifacts exhibiting the same features
and bugs every time I perform the operation against that label. I have
even worked in environments where the tools used to perform the build
(compilers, linkers, 3rd-party libraries) were stored under revision
control and executed from the sandbox.

In software development, version control systems play two roles. The
first is to coordinate the day-to-day changes performed by developers.
(Let us call this "change management".) The second is to provide a means
for unambiguously identifying software configurations for purposes of
ensuring repeatable builds. (Let us call this "software configuration
management".)

These roles are often joined because all of the information needed for
software configuration management usually already exists in the version
control system as a side-effect of change management for the vast majority
of the files. Furthermore, the files end up neatly packaged in a confined
space on the sandbox for the build and the repository provides a confined
context for backup. Therefore, all that remains is to get the few remaining
files into the repository so that they can be labeled and retrieved along
with the rest. CVS does this but it has correctable vulnerabilities that
would be reasonable to address.

Software configuration management is only effective if one system manages
the entire codebase. Therefore, this is the minimum support for binary files
that I would want to see. For change management, I can see arguments in
either direction, provided that CVS performed the actual versioning and
storage.

Ralph A. Mack