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

[Greg A. Woods]

[ On Friday, July 20, 2001 at 08:41:53 (-0400), Ralph Mack wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> > 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.

No, sorry, you are very wrong.

The diff program is always used to figure out what the delta between two
revisions is, and RCS simply logs that delta.

All RCS does (with -kb) to support the storage of binary files is to
suppress keyword expansion and to do I/O in "binary" mode (where that
really just means adding "b" to the flags argument of fopen()).  The
rcsmerge program (which uses diff3) also refuses to merge files when
'-kb' is in effect.  The delta stored in the RCS file is still
calculated with diff, (well, with "diff --binary" if '-kb' is in
effect).

from the co(1) manual:

       -kb    Generate  a binary image of the old keyword string.
              This acts like -ko, except it performs all  working
              file  input  and output in binary mode.  This makes
              little difference on Posix and Unix hosts,  but  on
              DOS-like  hosts  one  should use rcs -i -kb to ini-
              tialize an RCS file intended to be used for  binary
              files.   Also,  on  all hosts, rcsmerge(1) normally
              refuses to merge files when -kb is in effect.

from the ci(1) code:

#                   if OPEN_O_BINARY
                        if (Expand == BINARY_EXPAND)
                            *++diffp = "--binary";
#                   endif

Note also that "diff --binary" doesn't do anything magical either.  It
just tells diff to not bother checking for binary attributes of the
input files and to do I/O in "binary" mode.  It still does per-line
comparisons, but since it handles really long lines really well (at
least until you run out of VM), the result is effectively the same.

None of the binary handling of diff and diff3 and RCS makes it possible
to merge files with anywhere near the degree of success required by a
concurrent versioning tool (or a versioning tool which tries to automate
as much as possible of branching, which is why even with plain RCS,
which is not implicitly a concurrent versioning tool, its rcsmerge
program will flattly refuse to try to merge files you've declared to be
"binary").

Finally where you're most wrong is in ignoring this expectation CVS must
have of being able to normally perform automatic merges.  If you look
into the research and practical experience reports for any and all
concurrent versioning systems you'll learn that the sole reason they
succeed as well as they do is because they can norally do a fully
automatic and 100% successfull merge of changes to one or more files.
Even Berliner's CVS-II paper shows this quite clearly.

> > 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.

Hmm...  well, getting the "required files" out of the version control
system (presumably at the "required revision level") is only part of the
whole SCM process, now isn't it!

> 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.

Yes, that's what I said:  Your build system deals with software
configuration componets that are not source files stored in CVS.
I.e. it calls a compiler (which is a software configuration component)
to creates the product files.  If you're careful you've specified an
explicit version of the compiler in your makefiles.

> 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.

Your build is only 100% repeatable if you use the same tools.

> 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.

Yes, that's more what I'm talking about.  TCCS is an existing (freely
available) change control system with integrated release management and
it sort of has an integrated build system too (at least logically).

> Software configuration management is only effective if one system manages
> the entire codebase.

Well now, that's where you're wrong, or at least being very misleading.

A "system" doesn't have to be one integrated tool, such as TCCS.  A
system can be just a set of rules, guidelines, and procedures!

My "SCM" for some projects includes not only CVS, but GNU Make, GNU
Automake, GNU Autoconf, and a half decent unix-like system with a good C
compiler and related tools.  On top of that I've specified certain
procedures to be used for defining everthing from how to create a new
release, down to how to choose the name for a new release.

> 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.

CVS can only really be effective at versioning and storing mergable
content and therefore it cannot ever become an integrated SCM system.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>