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

[Ralph A Mack]

Hello, all,

> Quoth Greg Woods:

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

Ah, I am learning something here! The primary problem with simply storing
and retrieving binary files is that there is a finite probability that one
day a binary file will simply refuse to be retrieved. Let me see if the
above
information gives me a better understanding of the mechanism of this
problem:

If the file contains not one 0x0d character, it will treat the entire file
as a single line and thereby overflow even the most generous buffer. This
is why it can fail? In the more common case, of course, there will be a
generous sprinkling of accidental 0x0d characters and so it will work.
However this problem is almost guaranteed to surface under sufficient load.
All a remote unlikelyhood requires in order to become a near-certainty
of happening at least once is a sufficient sample size.

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

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

For the truly paranoid, the "required files" can include the closure of
software needed to build the system - yeah, that's a lot of binary files to
store. A less paranoid person might exclude those files for which version
changes are deemed least likely to have significant impact. (For instance,
include the compiler, linker, libraries, but leave out the operating system
kernel.) Here, by storing the versions of all the files, mergeable and not,
and all of the tools and build scripts in a single repository with a single
label, the repository serves as the software configuration management tool.

For the objectives of cross-platform projects, this kind of paranoia isn't
generally possible. For this kind of flexibility, tools like autoconf and
automake are essential in order to identify the available tools. In this
situation, configuration management is relaxed; without heroic efforts, the
expectation of getting precisely identical results must be slightly relaxed
as well. So the repository is still responsible for managing the software
configuration.

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

Aside from the integrated build system, the combination of change management
and
release management was what I had in mind. I'll have to evaluate TCCS - it
is new
to me. I presume it supports all sorts of files? Thinking of CVS in this
role,
the repository would have nothing to do with performing the build nor does
it
know anything about the build files. It just provides the right set of
nouns,
verbs, and adjectives. The user would say "fiat lux" to cause the system
checked
out of revision control to build itself. Hmmm..."fiat lux" = "make light" -
naw,
He/She couldn't have built the prototype on some Cosmic Unix :-)

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

As long as it only uses a single set of underlying tools (i.e. rcs, diff,
diff3) you are absolutely right. If it permitted different sets of tools to
operate on different kinds of files, as Paul Sander has argued, then it
could
operate conceptually identically as it does today but fully support a wider
range of files. I would only extend the model by allowing separate tools for
identifying and marking meaningful regions of difference between files and
for merging the differences thus marked. This allows for insertion of true
computer-assisted manual merge, etc.

I have heard the following objections voiced to recent suggestions,
objections
that I consider reasonable:
- It changes the conceptual space of CVS far beyond where it was ever
intended
  to go and could alienate the part of our customer base that expects CVS to
  remain confined to that space. It shouldn't be done.
- The work involved is heavy: we saw the large number of detailed work items
  involved in a change to track merges a month or two ago, and that was
trivial
  compared to this. Not only will it require development to produce a
submittable
  patch, it will require substantial effort to support it, fix bugs, etc.
and
  there's only two guys doing support. Thus, it can't be done with the
resources
  available at present.

Both may be true. Unfortunately, that doesn't get me where I want to go. So
once
again, I get to the point of "put up or shut up" and, as with merge
tracking, this
is also too big a task for me to contemplate under present circumstances.

Despite my limited time, I really would like to be involved in a project
like
this, though. My plan of action will be first to evaluate TCCS to see if it
is
closer to what I want. Then, if the fire still hasn't gone out for me on
CVS,
maybe I'll have a look at some items on the bug list. I don't have a lot of
time available, but bugs are often challenging but bounded problems that fit
well into limited time; chasing bugs is a great way to make a positive
contribution to a project. And - who knows - maybe a few extra hands on the
buglist will make it possible for someone who _does_ have the time to move
some of this into action.

Ralph A. Mack