Clarification of Answer by
maniac-ga
on
17 Jul 2003 18:28 PDT
Hello B_Ray,
I did not intend to mislead, but CVS is not currently a front end to
RCS. They do share file formats - easing the upgrade path from RCS to
CVS, but there are a number of capabilities in CVS that have no
equivalent in RCS. The original shell scripts were certainly a front
end to RCS, but the current code base has diverged in several
significant ways.
There is some overlap in the "CVS Philosophy" with RCS. For example:
- basic operations (check out, check in, versions) are similar
- format of difference files are almost identical
However, CVS was developed in part to support a different development
/ control methodology. For example, many developers can "check out" a
set of files. Others can make updates w/o requiring all the "checked
out" files to be updated. However, you cannot check in using CVS until
you have checked out the "latest version" or set up a branch to keep
your changes. For a large team, this kind of support is extremely
valuable and not available in RCS. In some of the papers I found, this
is described as the difference between "pessimistic" and "optimistic"
version control referring to RCS and CVS respectively.
About being standardized, I did a review of the online version of the
Single Unix Specification
http://www.unix.org/single_unix_specification/
and noted that neither CVS nor RCS are included. However, an older
version control system SCCS is included in the specification under the
shell and utilities section.
http://www.opengroup.org/onlinepubs/007904975/utilities/contents.html
I can't absolutely say there is no "official standard", but if there
is such a standard, it is hidden quite well and not referred to in
several locations.
Since you are talking about writing a paper, it may be helpful to use
a resource such as Citeseer as a guide. Using the paper you provided
as an example I pulled up
http://citeseer.nj.nec.com/context/98978/0
which lists 142 papers that refer to that paper by Tichy. Many of
these papers refer to both CVS and RCS. Picking one of those that
appeared to cover both in an equal manner led me to
http://citeseer.nj.nec.com/566791.html
and
http://citeseer.nj.nec.com/rd/89313789%2C566791%2C1%2C0.25%2CDownload/http%3AqSqqSqwww.isr.uci.eduqSq%7EandreqSqresearchqSqpapersqSqICSE2003-1.pdf
which refers to CVS[4] and points to a Usenix conference paper in 1990
which is accessible at
http://citeseer.nj.nec.com/berliner90cvs.html
if you want to see the original paper. This paper describes the
difference in philosophy, some implementation details, and refers to
other papers (but not on CVS directly).
To answer some of your other comments / questions about addressing a
more general audience, if I was writing something up, I would try to
keep it at a high level. Mention the product (CVS) by name and/or
acronym. Then describe some of the basic features (check in, check
out, multiple versions, efficient storage, ...) and move on. With
today's resources (e.g., Google) you can find the item by just knowing
its name instead of the address.
If they are unfamiliar with basic version control, you may need to
prepare some examples. For example, when I reviewed free / low cost
version control systems for development on Linux, I was greatly
impressed by the explanation of the effort used to import large
software items (e.g., Sun Unix source) and merge with local changes.
That particular capability may not be something you need, but there
are other examples that should serve as well.
About subversion (and similar items), I decided against deploying them
in our facility due to the level of product maturity. Yes, they have
additional features, but we opted for a low risk and mature product
that has wide understanding by developers. At some time, subversion
may get to the same level of maturity and support - but I expect to
see CVS in use for quite some time.
--Maniac
