rcs.ms

早期freebsd实现

Configuration Management
.PP
The preceding sections described how RCS deals with revisions of individual
components; this section discusses how to handle configurations.
A configuration is a set of revisions, where each revision comes
from a different revision group, and the revisions are selected
according to a certain criterion.
For example,
in order to build a functioning compiler, the `right'
revisions from the scanner, the parser, the optimizer
and the code generator must be combined.
RCS, in conjunction with MAKE,
provides a number of facilities to effect a smooth selection.
.NH 2
RCS Selection Functions
.PP
.IP "\fIDefault selection\fR"
.sp 0
During development, the usual selection criterion is to choose
the latest revision of all components.  The \fIco\fR command
makes this selection by default.  For example, the command
.D(
co  *,v
.D)
retrieves the latest revision on the default branch of each RCS file
in the current directory.
The default branch is usually the trunk, but may be
set to be a side branch.
Side branches as defaults are needed in distributed software development,
as discussed in the section on the RCS revision tree.
.sp
.IP "\fIRelease based selection\fR"
.sp 0
Specifying a release or branch number selects the latest revision in
that release or branch.
For instance,
.D(
co  \-r2  *,v
.D)
retrieves the latest revision with release number 2 from each RCS file.
This selection is convenient if a release has been completed and
development has moved on to the next release.
.sp
.IP "\fIState and author based selection\fR"
.sp 0
If the highest level number within a given release number
is not the desired one,
the state attribute can help.  For example,
.D(
co  \-r2  \-sReleased  *,v
.D)
retrieves the latest revision with release number 2 whose state attribute
is `Released'.
Of course, the state attribute has to be set appropriately, using the
\fIci\fR or \fIrcs\fR commands.
Another alternative is to select a revision by its author,
using the \fI\-w\fR option.
.sp
.IP "\fIDate based selection\fR"
.sp 0
Revisions may also be selected by date.
Suppose a release of an entire system was
completed and current on March 4, at 1:00 p.m. local time.  Then the command
.D(
co  \-d'March 4, 1:00 pm LT'  *,v
.D)
checks out all the components of that release, independent of the numbering.
The \fI\-d\fR option specifies a `cutoff date', i.e.,
the revision selected has a check-in date that
is closest to, but not after the date given.
.IP "\fIName based selection\fR"
.sp 0
The most powerful selection function is based on assigning symbolic
names to revisions and branches.
In large systems, a single release number or date is not sufficient
to collect the appropriate revisions from all groups.
For example, suppose one wishes to combine release 2
of one subsystem and release 15 of another.
Most likely, the creation dates of those releases differ also.
Thus, a single revision number or date passed to the \fIco\fR command
will not suffice to select the right revisions.
Symbolic revision numbers solve this problem.
Each RCS file may contain a set of symbolic names that are mapped
to numeric revision numbers.  For example, assume
the symbol \fIV3\fR is bound to release number 2 in file \fIs,v\fR, and to
revision number 15.9 in \fIt,v\fR.
Then the single command
.D(
co  \-rV3  s,v  t,v
.D)
retrieves the latest revision of release 2 from \fIs,v\fR,
and revision 15.9 from \fIt,v\fR.
In a large system with many modules, checking out all
revisions with one command greatly simplifies configuration management.
.PP
Judicious use of symbolic revision numbers helps with organizing
large configurations.
A special command, \fIrcsfreeze\fR,
assigns a symbolic revision number to a selected revision
in every RCS file.
\fIRcsfreeze\fR effectively freezes a configuration.
The assigned symbolic revision number selects all components
of the configuration.
If necessary, symbolic numbers
may even be intermixed with numeric ones.  Thus, \fIV3.5\fR in the
above example
would select revision 2.5 in \fIs,v\fR and branch 15.9.5 in \fIt,v\fR.
.PP
The options \fI\-r\fR, \fI\-s\fR, \fI\-w\fR and \fI\-d\fR
may be combined.  If a branch is given, the latest revision
on that branch satisfying all conditions is retrieved;
otherwise, the default branch is used.
.NH 2
Combining MAKE and RCS
.PP
MAKE\u1\d
is a program that processes configurations.
It is driven by configuration specifications
recorded in a special file, called a `Makefile'.
MAKE avoids redundant processing steps
by comparing creation dates of source and processed objects.
For example, when instructed to compile all
modules of a given system, it only recompiles
those source modules that were changed
since they were processed last.
.PP
MAKE has been extended with an auto-checkout feature for RCS.*
.FS *
This auto-checkout extension is available only in some versions of MAKE,
e.g. GNU MAKE.
.FE
When a certain file to be processed is not present,
MAKE attempts a check-out operation.
If successful, MAKE performs the required processing, and then deletes
the checked out file to conserve space.
The selection parameters discussed above can be passed to MAKE
either as parameters, or directly embedded in the Makefile.
MAKE has also been extended to search the subdirectory named \fIRCS\fR
for needed files, rather than just the current working directory.
However, if a working file is present, MAKE totally ignores the corresponding
RCS file and uses the working file.
(In newer versions of MAKE distributed by AT&T and others,
auto-checkout can be
achieved with the rule DEFAULT, instead of a special extension of MAKE.
However, a file checked out by the rule DEFAULT
will not be deleted after processing. \fIRcsclean\fR can be
used for that purpose.)
.PP
With auto-checkout, RCS/MAKE can effect a selection rule
especially tuned for multi-person software development and maintenance.
In these situations,
programmers should obtain configurations that consist of
the revisions they have personally checked out plus the latest
checked in revision of all other revision groups.
This schema can be set up as follows.
.PP
Each programmer chooses a working directory
and places into it a symbolic link, named \fIRCS\fR,
to the directory containing the relevant RCS files.
The symbolic link makes sure that \fIco\fR and \fIci\fR
operations need only specify the working files, and that
the Makefile need not be changed.
The programmer then checks out the needed files and modifies them.
If MAKE is invoked,
it composes configurations by selecting those
revisions that are checked out, and the rest from the
subdirectory \fIRCS\fR.
The latter selection may be controlled by a symbolic
revision number or any of the other selection criteria.
If there are several programmers editing in separate working directories,
they are insulated from each other's changes until checking in their
modifications.
.PP
Similarly, a maintainer can recreate an older configuration
by starting to work in an empty working directory.
During the initial MAKE invocation, all revisions are selected from RCS files.
As the maintainer checks out files and modifies them,
a new configuration is gradually built up.
Every time MAKE is invoked, it substitutes the modified revisions
into the configuration being manipulated.
.PP
A final application of RCS is to use it for storing Makefiles.
Revision groups of Makefiles represent
multiple versions of configurations.
Whenever a configuration is baselined or distributed,
the best approach is to unambiguously fix
the configuration with a symbolic revision number by calling
\fIrcsfreeze\fR,
to embed that symbol into the Makefile, and to
check in the Makefile (using the same symbolic revision number).
With this approach, old configurations
can be regenerated easily and reliably.
.NH
Usage Statistics
.PP
The following usage statistics were collected on two DEC VAX-11/780
computers of the Purdue Computer Science Department.  Both machines
are mainly used for research purposes.  Thus, the data
reflect an environment in which the majority of projects
involve prototyping and advanced software development,
but relatively little long-term maintenance.
.PP
For the first experiment,
the \fIci\fR and \fIco\fR operations were instrumented
to log the number of backward and forward deltas applied.
The data were collected during a 13 month period
from Dec. 1982 to Dec. 1983.
Table I summarizes the results.
.sp 0
.nr VS 12p
.vs 12p
.TS
center,box,tab(#);
c|c|c|c|c s|c s
c|c|c|c|c s|c s
l|n|n|n|n n|n n.
Operation#Total#Total deltas#Mean deltas#Operations#Branch
	 #operations #applied#applied#with >1 delta#operations
_
co     # 7867# 9320#1.18#509#(6%)#203#(3%)
ci     # 3468# 2207#0.64# 85#(2%)# 75#(2%)
ci & co#11335#11527#1.02#594#(5%)#278#(2%)
.TE
.ce 1
Table I.  Statistics for \fIco\fR and \fIci\fR operations.
.nr VS 18p
.vs 18p
.PP
The first two lines show statistics for check-out and check-in;
the third line shows the combination.
Recall that \fIci\fR performs an implicit check-out to obtain
a revision for computing the delta.
In all measures presented, the most recent revision (stored intact)
counts as one delta.  The number of deltas applied represents
the number of passes necessary, where the first `pass' is a copying step.
.PP
Note that the check-out operation is executed more than
twice as frequently as the check-in operation.
The fourth column gives the mean number of deltas
applied in all three cases.
For \fIci\fR, the mean number of deltas applied is less
than one.
The reasons are that the initial check-in requires no delta at all, and that
the only time \fIci\fR requires more than one delta is for branches.
Column 5 shows the actual number of operations that applied more than one
delta.
The last column indicates that branches were not used often.
.PP
The last three columns demonstrate that the most recent trunk revision
is by far the most frequently accessed.
For RCS, check-out of
this revision is a simple copy operation, which is the absolute minimum
given the copy-semantics of \fIco\fR.
Access to older revisions and branches
is more common in non-academic environments,
yet even if access to older deltas were an order
of magnitude more frequent,
the combined average number of deltas applied would still be below 1.2.
Since RCS is faster than SCCS until up to 10 delta applications,
reverse deltas are clearly the method of choice.
.PP
The second experiment, conducted in March of 1984,
involved surveying the existing RCS files
on our two machines.  The goal was to determine the mean number of
revisions per RCS file, as well as the space consumed by them.
Table II shows the results.  (Tables I and II were produced at different
times and are unrelated.)
.sp 0
.nr VS 12p
.vs 12p
.TS
center,box,tab(#);
c | c | c | c | c | c | c
c | c | c | c | c | c | c
l | n | n | n | n | n | n.
	  #Total RCS#Total#Mean#Mean size of#Mean size of#Overhead
	  #files#revisions#revisions#RCS files#revisions
_
All files #8033#11133#1.39#6156#5585#1.10
Files with#1477# 4578#3.10#8074#6041#1.34
\(>= 2 deltas
.TE
.ce 1
Table II.  Statistics for RCS files.
.nr VS 18p
.vs 18p
.PP
The mean number of revisions per RCS file is 1.39.
Columns 5 and 6 show the mean sizes (in bytes) of an RCS file
and of the latest revision of each RCS file, respectively.
The `overhead' column contains the ratio of the mean sizes.
Assuming that all revisions in an RCS file are approximately the same size,
this ratio gives a measure of the space consumed by the extra revisions.
.PP
In our sample, over 80 per cent of the RCS files contained only a single revision.
The reason is that our
systems programmers routinely check in all source files
on the distribution tapes, even though they may never touch them again.
To get a better indication of how much space savings are possible
with deltas, all measures with those files
that contained 2 or more revisions were recomputed.  Only for those files
is RCS necessary.
As shown in the second line, the average number of revisions for those files is
3.10, with an overhead of 1.34.  This means that the extra 2.10 deltas
require 34 per cent extra space, or
16 per cent per extra revision.
Rochkind\u3\d
measured the space consumed by SCCS, and
reported an average of 5 revisions per group
and an overhead of 1.37 (or about 9 per cent per extra revision).
In a later paper, Glasser\u6\d
observed an average of 7 revisions per group in a single, large project,
but provided no overhead figure.
In his paper on DSEE\u5\d,
Leblang reported that delta storage combined with blank compression
results in an overhead of a mere 1\-2 per cent per revision.
Since leading blanks accounted for about 20 per cent of the surveyed Pascal
programs, a revision group with 5\-10 members was smaller
than a single cleartext copy.
.PP
The above observations demonstrate clearly that the space needed
for extra revisions is small.  With delta storage, the luxury of
keeping multiple revisions online is certainly affordable.
In fact, introducing a system with delta storage may reduce
storage requirements, because programmers often save back-up copies
anyway.  Since back-up copies are stored much more efficiently with deltas,
introducing a system such as RCS may
actually free a considerable amount of space.
.NH
Survey of Version Control Tools
.PP
The need to keep back-up copies of software arose when
programs and data were no longer stored on paper media, but were entered
from terminals and stored on disk.
Back-up copies are desirable for reliability, and many modern editors
automatically save a back-up copy for every file touched.
This strategy
is valuable for short-term back-ups, but not suitable for long-term
version control, since an existing back-up copy is overwritten whenever the
corresponding file is edited.
.PP
Tape archives are suitable for long-term, offline storage.
If all changed files are dumped on a back-up tape once per day, old revisions
remain accessible.  However, tape archives are unsatisfactory
for version control in several ways.  First, backing up the file
system every 24 hours does not capture intermediate revisions.
Secondly, the old revisions are not online,
and accessing them is tedious and time-consuming.
In particular, it is impractical to
compare several old revisions of a group,
because that may require mounting and searching several tapes.
Tape archives are important fail-safe tools in the
event of catastrophic disk failures or accidental deletions,
but they are ill-suited for version control.
Conversely, version control tools do not obviate the
need for tape archives.
.PP
A natural technique for keeping several old revisions online is
to never delete a file.
Editing a file
simply creates a new file with the same
name, but with a different sequence number.
This technique, available as an option in DEC's VMS operating system,
turns out to be inadequate for version control.
First, it is prohibitively expensive in terms of storage costs,
especially since no data compression techniques are employed.
Secondly, indiscriminately storing every change produces too many
revisions, and programmers have difficulties distinguishing them.
The proliferation of revisions forces programmers to spend much time on
finding and deleting useless files.
Thirdly, most of the support functions like locking, logging,
revision selection,
and identification described in this paper are not available.
.PP
An alternative approach is to separate editing from revision control.
The user may repeatedly edit a given revision,
until freezing it with an explicit command.
Once a revision is frozen, it is stored permanently and can no longer be modified.
(In RCS, freezing a revisions is done with \fIci\fR.)
Editing a frozen revision implicitly creates a new one, which
can again be changed repeatedly until it is frozen itself.
This approach saves exactly those revisions that the user