File rcs.html of Package rcs
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN">
<HTML>
<!-- Texinfo converting Tools Release 1.00 -->
<!-- (c) by Andreas Kaiser 1996 (c) by Karl Heinz Marbaise 1997 -->
<HEAD>
<TITLE>(R)evision (C)ontrol (S)ystem</TITLE>
</HEAD>
<BODY>
<H1>Preface</H1>
<P>This file documents the Revision Control System (RCS).
<P>Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.
<P>Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
<P>Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that this permission notice may be stated in a translation approved
by the Foundation.
<P>Copyright © 1982, 1988, 1989 Walter F. Tichy.
<P>Copyright © 1990, 1991, 1992, 1993, 1994, 1995 Paul Eggert.
<P>Copyright © 1996, 1997 Karl Heinz Marbaise (doing converting job)
<A NAME="Top"></A>
<P>This manual(Edition 1.1) documents version 5.7
of the Revision Control System (RCS).
<UL>
</UL>
-- About the manual --
<UL>
<LI><A HREF="#About">About the manul.</A>
<LI><A HREF="#AboutDesc">Informations about that manual.</A>
<LI><A HREF="#Versions">Versions of the troff/nroff manuals.</A>
<LI><A HREF="#BugReport">Bugs? suggestions?</A>
</UL>
-- RCS - A System for Version Control --
<UL>
<LI><A HREF="#VersionControl">RCS -- A System for Version Control.</A>
<LI><A HREF="#Introduction">Introduction to RCS.</A>
<LI><A HREF="#StartRCS">Getting started with RCS.</A>
<LI><A HREF="#Identification">Automatic Identification.</A>
<LI><A HREF="#RevisionTree">The RCS Revision Tree.</A>
<LI><A HREF="#Branches">When are branches needed?.</A>
<LI><A HREF="#Deltas">Revisions are represented as deltas.</A>
<LI><A HREF="#Controversial">Locking: A Controversial Issue.</A>
<LI><A HREF="#Configuration">Configuration Management.</A>
<LI><A HREF="#Functions">RCS Selection Functions.</A>
<LI><A HREF="#MAKERCS">Combining MAKE and RCS.</A>
<LI><A HREF="#Statistics">Usage Statistics.</A>
<LI><A HREF="#Survey">Survey of Version Control Tools.</A>
</UL>
-- rcsintro - introduction to RCS commands --
<UL>
<LI><A HREF="#rcsIntroduction">Introduction to RCS commands.</A>
<LI><A HREF="#rcsintroDesc">Introduction to <CODE>RCS</CODE>.</A>
<LI><A HREF="#rcsintroFunc">Functions of <CODE>RCS</CODE>.</A>
<LI><A HREF="#rcsintroStart">Getting started with <CODE>RCS</CODE>.</A>
<LI><A HREF="#rcsintroAutoIdent">Automatic identification.</A>
</UL>
-- Synopsis of RCS Operations --
<UL>
<LI><A HREF="#Synopsis">Synopsis of RCS Operations.</A>
</UL>
-- ci - check in RCS revsisions --
<UL>
<LI><A HREF="#CheckIn">ci -- check in RCS revsisions.</A>
<LI><A HREF="#ciIntro">Introduction to <CODE>ci</CODE>.</A>
<LI><A HREF="#ciEnv">Environment which can change the behaviour of <CODE>ci</CODE> and other RCS commands.</A>
<LI><A HREF="#ciFileModes">File modes.</A>
<LI><A HREF="#ciFiles">Files.</A>
<LI><A HREF="#setuid use">Using of uid.</A>
<LI><A HREF="#ciExamples">Examples.</A>
<LI><A HREF="#ciDiag">Diagnostic output of <CODE>ci</CODE>.</A>
<LI><A HREF="#ciOptions">command line options of <CODE>ci</CODE>.</A>
</UL>
-- co - check out RCS revsisions --
<UL>
<LI><A HREF="#CheckOut">co -- check out RCS revsisions</A>
<LI><A HREF="#coIntro">Introduction to <CODE>co</CODE>.</A>
<LI><A HREF="#coOptions">command line options of <CODE>co</CODE>.</A>
<LI><A HREF="#coKeyword">Keyword expansion and valid keywords.</A>
<LI><A HREF="#coEnv">Environment which can change the behaviour of <CODE>co</CODE> and other RCS commands.</A>
<LI><A HREF="#coFileModes">File modes.</A>
<LI><A HREF="#coFiles">Files.</A>
<LI><A HREF="#coDiag">Diagnostic output of <CODE>co</CODE>.</A>
<LI><A HREF="#coLimits">Limits.</A>
</UL>
-- rcs - change RCS file attributes --
<UL>
<LI><A HREF="#rcs">rcs -- change RCS file attributes.</A>
<LI><A HREF="#rcsIntro">Introduction to <CODE>rcs</CODE>.</A>
<LI><A HREF="#rcsOptions">command line options of <CODE>rcs</CODE>.</A>
<LI><A HREF="#rcsCompatibility">Compatibility between RCS Versions.</A>
<LI><A HREF="#rcsFiles">Files.</A>
<LI><A HREF="#rcsEnv">The Environment which can change the behaviour of much of the RCS commands.</A>
<LI><A HREF="#rcsDiag">Diagnostic output of <CODE>rcs</CODE>.</A>
<LI><A HREF="#rcsBugs">Bugs.</A>
</UL>
-- ident - identify RCS keyword strings in files --
<UL>
<LI><A HREF="#ident">ident -- identify RCS keyword strings in files.</A>
<LI><A HREF="#identIntro">Introduction to <CODE>rcs</CODE>.</A>
<LI><A HREF="#identOptions">command line options of <CODE>rcs</CODE>.</A>
<LI><A HREF="#identKeywords">Keywords.</A>
</UL>
-- rcsclean - clean up working files --
<UL>
<LI><A HREF="#rcsclean">rcsclean -- clean up working files.</A>
<LI><A HREF="#rcscleanIntro">Introduction to <CODE>rcsclean</CODE>.</A>
<LI><A HREF="#rcscleanOptions">command line options of <CODE>rcsclean</CODE>.</A>
<LI><A HREF="#rcscleanExamples">Examples in using <CODE>rcsclean</CODE>.</A>
<LI><A HREF="#rcscleanFiles">Files.</A>
<LI><A HREF="#rcscleanEnv">The Environment which can change the behaviour of much of the RCS commands.</A>
<LI><A HREF="#rcscleanDiag">Diagnostic output of <CODE>rcsclean</CODE>.</A>
<LI><A HREF="#rcscleanBugs">Bugs.</A>
</UL>
-- rcsdiff -- compare RCS revisions --
<UL>
<LI><A HREF="#rcsdiff">rcsdiff -- compare RCS revisions.</A>
<LI><A HREF="#rcsdiffIntro">Introduction to <CODE>rcsdiff</CODE>.</A>
<LI><A HREF="#rcsdiffOptions">command line options of <CODE>rcsdiff</CODE>.</A>
<LI><A HREF="#rcsdiffExamples">Examples in using <CODE>rcsdiff</CODE>.</A>
<LI><A HREF="#rcsdiffEnv">The Environment which can change the behaviour of much of the RCS commands.</A>
<LI><A HREF="#rcsdiffDiag">Diagnostic output of <CODE>rcsdiff</CODE>.</A>
</UL>
-- rcsmerge -- merge RCS versions --
<UL>
<LI><A HREF="#rcsmerge">rcsmerge -- merge RCS versions.</A>
<LI><A HREF="#rcsmergeIntro">Introduction to <CODE>rcs</CODE>.</A>
<LI><A HREF="#rcsmergeOptions">command line options of <CODE>rcs</CODE>.</A>
<LI><A HREF="#rcsmergeExamples">Examples of <CODE>rcsmerge</CODE>.</A>
<LI><A HREF="#rcsmergeEnv">The Environment which can change the behaviour of much of the RCS commands.</A>
<LI><A HREF="#rcsmergeDiag">Diagnostic output of <CODE>rcs</CODE>.</A>
</UL>
-- rlog -- print log messages and other information about RCS files --
<UL>
<LI><A HREF="#rlog">rlog -- print log messages and other information about RCS files.</A>
<LI><A HREF="#rlogIntro">Introduction to <CODE>rlog</CODE>.</A>
<LI><A HREF="#rlogOptions">command line options of <CODE>rlog</CODE>.</A>
<LI><A HREF="#rlogExamples">Examples.</A>
<LI><A HREF="#rlogEnv">The Environment which can change the behaviour of much of the RCS commands.</A>
<LI><A HREF="#rlogDiag">Diagnostic output of <CODE>rlog</CODE>.</A>
<LI><A HREF="#rlogBugs">Bugs.</A>
</UL>
-- merge -- three-way file merge --
<UL>
<LI><A HREF="#merge">merge -- three-way file merge.</A>
<LI><A HREF="#mergeIntro">Introduction to <CODE>merge</CODE>.</A>
<LI><A HREF="#mergeOptions">command line options of <CODE>merge</CODE>.</A>
<LI><A HREF="#mergeDiag">Diagnostic output of <CODE>merge</CODE>.</A>
<LI><A HREF="#mergeBugs">Bugs.</A>
</UL>
------------ Appendencies ------------
<UL>
</UL>
-- Appendix A --
<UL>
<LI><A HREF="#AppendixA">Format of RCS file.</A>
</UL>
-- Appendix B --
<UL>
<LI><A HREF="#AppendixB">Books and related manuals.</A>
<LI><A HREF="#Feldman">GNU - Make.</A>
<LI><A HREF="#Hunt">GNU - diff.</A>
<LI><A HREF="#Rochkind">SCCS.</A>
<LI><A HREF="#Tichy">Design and implementation of RCS.</A>
<LI><A HREF="#Leblang">Computer-Aided Software Engineering.</A>
<LI><A HREF="#Glasser">The Evolution of a Source Code Control System.</A>
<LI><A HREF="#Brown">The Clear/Caster System.</A>
<LI><A HREF="#Habermann">A Software Development Control System.</A>
<LI><A HREF="#DEC">Code Management System.</A>
<LI><A HREF="#Lampson">Practical Use of a Polymorphic Applicative Language.</A>
<LI><A HREF="#Tichy1">A Data Model for Programming Support Environments and its Application.</A>
<LI><A HREF="#Heckel">A Technique for Isolating Differences Between Files.</A>
<LI><A HREF="#Tichy2">The String-to-String Correction Problem with Block Moves.</A>
<LI><A HREF="#Index">Concept Index.</A>
</UL>
<A NAME="About"></A>
<H1><A NAME="hd_2">About the manual</A></H1>
<A NAME="cp_About"></A>
<UL>
<LI><A HREF="#AboutDesc">Informations about that manual.</A>
<LI><A HREF="#Versions">Versions of the troff/nroff manuals.</A>
<LI><A HREF="#BugReport">Bugs? suggestions?</A>
</UL>
<A NAME="AboutDesc"></A>
<H2><A NAME="hd_3">Description</A></H2>
<P>These 'Texinfo' files are hand converted out of the
troff/nroff files, which came with the RCS system.
<P>This has done by hand, cause there does not exist a converter
which is able to convert (nroff/troff) into GNU's 'Texinfo' format
(I know one, which is able to do the other way,'texinfo' to nroff).
<P>The main reason for doing such a stupid work was, to have the opinion
to convert the 'Texinfo' into OS/2-IPF format.
This conversion is done with "Texinfo converting Tools Release 1.00"
which are able to convert to OS/2-IPF format and HTML(not the Perl-script).
<P>The next possibility is to get a well printed manual, using
TeX(I use emTeX myself).
<P>This is the first Edition of this manuals, so don't be angry about
the cryptic node names within the 'Texinfo' files.
That's the only way to have unique node names for alle command line options.
And by the way this is the only way to make references to command line
options of every command.
<P>The next thing is to make this manual a little more readable, that means
not to double subsection with command line options on every command
(rlog, rcs, rcsdiff, ···).
The way out of this dilemma is to discribe these options within
a chapter 'overall options' or 'global options' which can be used on every
command(rlog, rcs, rcsdiff···).
But this will be done in the next edition, if you like it.
<P>If you like to make a printed manual yourself, you have to TeX it with
the 'texinfo' macro package(V2.185), it also works with
version 2.150 of the package. It should also work with edition 2 of the
'Texinfo' macro package.
<A NAME="Versions"></A>
<H2><A NAME="hd_4">Versions</A></H2>
<P>If you found newer versions of troff/nroff manual then please mail to me.
<P>Here are the exact RCS--versions of the troff/roff pages for
checking:
<UL>
<LI>Identification of the "RCS -- A System for Version Control"
<BR>
manual part (rcs.ms):
<PRE>
$Id: rcs.ms,v 5.4 1995/06/01 16:23:43 eggert Exp $
</PRE>
<LI>Identification of the ci manual part(ci.1):
<BR>
<PRE>
$Id: ci.1,v 5.17 1995/06/16 06:19:24 eggert Exp $
</PRE>
<LI>Identification of the co manual part(co.1):
<BR>
<PRE>
$Id: co.1,v 5.13 1995/06/01 16:23:43 eggert Exp $
</PRE>
<LI>Identification of the rcs manual part(rcs.1):
<BR>
<PRE>
$Id: rcs.1,v 5.13 1995/06/05 08:28:35 eggert Exp $
</PRE>
<LI>Identification of the ident manual part(ident.1):
<BR>
<PRE>
$Id: ident.1,v 5.4 1993/11/09 17:40:15 eggert Exp $
</PRE>
<LI>Identification of the rcsclean manual part(rcsclean.1):
<BR>
<PRE>
$Id: rcsclean.1,v 1.12 1993/11/03 17:42:27 eggert Exp $
</PRE>
<LI>Identification of the rcsdiff manual part(rcsdiff.1):
<BR>
<PRE>
$Id: rcsdiff.1,v 5.5 1993/11/03 17:42:27 eggert Exp $
</PRE>
<LI>Identification of the rcsmerge manual part(rcsmerge.1):
<BR>
<PRE>
$Id: rcsmerge.1,v 5.6 1995/06/01 16:23:43 eggert Exp $
</PRE>
<LI>Identification of the rlog manual part(rlog.1):
<BR>
<PRE>
$Id: rlog.1,v 5.9 1995/06/16 06:19:24 eggert Exp $
</PRE>
<LI>Identification of the merge manual part(merge.1):
<BR>
<PRE>
$Id: merge.1,v 5.7 1995/06/01 16:23:43 eggert Exp $
</PRE>
</UL>
<A NAME="BugReport"></A>
<H2><A NAME="hd_5">Bugs?, suggestions?</A></H2>
If you think you have found a bug within this manual, you could write
by electronic mail a report.
<P>Also, if you have suggestions for this manual.
Changes of chapters, sections and so on.
<P>Do you have good examples for this manual?
<P>Or what else you like.
<P>Please write to me:
<PRE>
Karl Heinz Marbaise
KHMarbaise@p69.ks.fido.de
Fido-Net: 2:2452/117.69
</PRE>
<A NAME="VersionControl"></A>
<H1><A NAME="hd_6">RCS--A System for Version Control</A></H1>
<P ALIGN=CENTER>Walter F. Tichy</P><P ALIGN=CENTER>Department of Computer Sciences</P><P ALIGN=CENTER>Purdue University</P><P ALIGN=CENTER>West Lafayette, Indiana 47907</P><P>An important problem in program development and maintenance is
version control, i.e., the task of keeping a software system
consisting of many versions and configurations well organized.
The Revision Control System (RCS) is a software tool that assists
with that task. RCS manages revisions of text documents, in
particular source programs, documentation, and test data. It
automates the storing, retrieval, logging and identification of
revisions, and it provides selection mechanisms for composing
configurations. This paper introduces basic version control
concepts and discusses the practice of version control using RCS.
For conserving space, RCS stores deltas, i.e., differences
between successive revisions. Several delta storage methods are
discussed. Usage statistics show that RCS's delta storage method
is space and time efficient. The paper concludes with a detailed
survey of version control tools.
<P>Keywords: configuration management, history management,
version control, revisions, deltas.
<P>An earlier version of this paper was published in
<CITE>Software--Practice & Experience, 7 (July 1985), 637-654.</CITE>
<UL>
<LI><A HREF="#Introduction">Introduction to RCS.</A>
<LI><A HREF="#StartRCS">Getting started with RCS.</A>
<LI><A HREF="#Identification">Automatic Identification.</A>
<LI><A HREF="#RevisionTree">The RCS Revision Tree.</A>
<LI><A HREF="#Branches">When are branches needed?.</A>
<LI><A HREF="#Deltas">Revisions are represented as deltas.</A>
<LI><A HREF="#Controversial">Locking: A Controversial Issue.</A>
<LI><A HREF="#Configuration">Configuration Management.</A>
<LI><A HREF="#Functions">RCS Selection Functions.</A>
<LI><A HREF="#MAKERCS">Combining MAKE and RCS.</A>
<LI><A HREF="#Statistics">Usage Statistics.</A>
<LI><A HREF="#Survey">Survey of Version Control Tools.</A>
</UL>
<A NAME="Introduction"></A>
<H2><A NAME="hd_7">Introduction</A></H2>
<P>Version control is the task of keeping software systems
consisting of many versions and configurations well organized.
The Revision Control System (RCS) is a set of UNIX commands that
assist with that task.
<P>RCS' primary function is to manage <B>revision groups</B>. A
revision group is a set of text documents, called <B>revisions</B>,
that evolved from each other. A new revision is created by
manually editing an existing one. RCS organizes the revisions
into an ancestral tree. The initial revision is the root of the
tree, and the tree edges indicate from which revision a given one
evolved. Besides managing individual revision groups, RCS
provides flexible selection functions for composing
configurations. RCS may be combined with MAKE (See <A HREF="#Feldman">Feldman</A>),
resulting in a powerful package for version control.
<P>RCS also offers facilities for merging updates with customer
modifications, for distributed software development, and for
automatic identification. Identification is the <TT>stamping</TT>
of revisions and configurations with unique markers. These
markers are akin to serial numbers, telling software maintainers
unambiguously which configuration is before them.
<P>RCS is designed for both production and experimental
environments. In production environments, access controls detect
update conflicts and prevent overlapping changes. In experimental
environments, where strong controls are counterproductive, it is
possible to loosen the controls.
<P>Although RCS was originally intended for programs, it is useful
for any text that is revised frequently and whose previous
revisions must be preserved. RCS has been applied successfully
to store the source text for drawings, VLSI layouts,
documentation, specifications, test data, form letters and
articles.
<P>This paper discusses the practice of version control using RCS.
It also introduces basic version control concepts, useful for
clarifying current practice and designing similar systems.
Revision groups of individual components are treated in the next
three sections, and the extensions to configurations follow.
Because of its size, a survey of version control tools appears at
the end of the paper.
<A NAME="StartRCS"></A>
<H2><A NAME="hd_8">Getting started with RCS</A></H2>
<P>Suppose a text file <TT>f.c</TT> is to be placed under control of
RCS. Invoking the check-in command
<PRE>
ci f.c
</PRE>
<P>creates a new revision group with the contents of <TT>f.c</TT> as
the initial revision (numbered 1.1) and stores the group into the
file <TT>f.c,v</TT>. Unless told otherwise, the command deletes
<TT>f.c</TT>. It also asks for a description of the group. The
description should state the common purpose of all revisions in
the group, and becomes part of the group's documentation. All
later check-in commands will ask for a log entry, which should
summarize the changes made. (The first revision is assigned a
default log message, which just records the fact that it is the
initial revision.)
<P>Files ending in <TT>,v</TT> are called <B>RCS files</B>
(<B>v</B> stands for <B>Rersions</B>); the others are called working
files. To get back the working file <TT>f.c</TT> in the previous
example, execute the check-out command:
<PRE>
co f.c
</PRE>
<P>This command extracts the latest revision from the revision group
<TT>f.c,v</TT> and writes it into <TT>f.c</TT>. The file <TT>f.c</TT>
can now be edited and, when finished, checked back in with
<CODE>ci</CODE>:
<PRE>
ci f.c
</PRE>
<P><CODE>Ci</CODE> assigns number 1.2 to the new revision.
If <CODE>ci</CODE> complains with the message
<PRE>
ci error: no lock set by <login>
</PRE>
<P>then the system administrator has decided to configure RCS for a
production environment by enabling the <TT>strict locking
feature</TT>. If this feature is enabled, all RCS files are
initialized such that check-in operations require a lock on the
previous revision (the one from which the current one evolved).
Locking prevents overlapping modifications if several people work
on the same file. If locking is required, the revision should
have been locked during the check-out by using the option
<CODE>-l</CODE>:
<PRE>
co -l f.c
</PRE>
<P>Of course it is too late now for the check-out with locking,
because <TT>f.c</TT> has already been changed; checking out the
file again would overwrite the modifications. (To prevent
accidental overwrites, <CODE>co</CODE> senses the presence of a working
file and asks whether the user really intended to overwrite it.
The overwriting check-out is sometimes useful for backing up to
the previous revision.) To be able to proceed with the check-in
in the present case, first execute
<PRE>
rcs -l f.c
</PRE>
<P>command retroactively locks the latest revision, unless someone
else locked it in the meantime. In this case, the two
programmers involved have to negotiate whose modifications should
take precedence.
<P>If an RCS file is private, i.e., if only the
owner of the file is expected to deposit revisions into it, the
strict locking feature is unnecessary and may be disabled. If
strict locking is disabled, the owner of the RCS file need not
have a lock for check-in. For safety reasons, all others still
do. Turning strict locking off and on is done with the commands:
<PRE>
rcs -U f.c and rcs -L f.c
</PRE>
<P>These commands enable or disable the strict locking feature for each
RCS file individually. The system administrator only decides
whether strict locking is enabled initially.
<P>To reduce the clutter in a working directory, all RCS files can
be moved to a subdirectory with the name <CODE>RCS</CODE>. RCS commands
look first into that directory for RCS files. All the commands
presented above work with the <CODE>RCS</CODE>
subdirectory<A HREF="#fn1">(1)</A><FN NAME="fn1">Pairs of RCS and working files can actually
be specified in 3 ways: a) both are given, b) only the working
file is given, c) only the RCS file is given. If a pair is given,
both files may have arbitrary path prefixes; RCS commands pair
them up intelligently</FN>. without change.
<P>It may be undesirable that <CODE>ci</CODE> deletes the working file.
For instance, sometimes one would like
to save the current revision, but continue editing. Invoking
<PRE>
ci -l f.c
</PRE>
<P>checks in <TT>f.c</TT> as usual, but performs an additional
check-out with locking afterwards. Thus, the working file does
not disappear after the check-in. Similarly, the option <CODE>-u</CODE>
does a check-in followed by a check-out without locking. This
option is useful if the file is needed for compilation after the
check-in. Both options update the identification markers in the
working file (see below).
<P>Besides the operations <CODE>ci</CODE> and <CODE>co</CODE>, RCS provides the
following commands:
<DL><DT>ident
<BR>
<DD>extract identification markers
<DT>rcs
<BR>
<DD>change RCS file attributes
<DT>rcsclean
<BR>
<DD>remove unchanged working files (optional)
<DT>rcsdiff
<BR>
<DD>compare revisions
<DT>rcsfreeze
<BR>
<DD>record a configuration (optional)
<DT>rcsmerge
<BR>
<DD>merge revisions
<DT>rlog
<BR>
<DD>read log messages and other information in RCS files
</DL>
<P>A synopsis of these commands appears in the Appendix.
<A NAME="Identification"></A>
<H3><A NAME="hd_9">Automatic Identification</A></H3>
<P>RCS can stamp source and object code with special identification
strings, similar to product and serial numbers. To obtain such
identification, place the marker
<PRE>
$Id$
</PRE>
<P>into the text of a revision, for instance inside a comment.
The check-out operation will replace this marker with a string of the form
<PRE>
$Id: filename revisionnumber date time author state locker $
</PRE>
<P>This string need never be touched, because <CODE>co</CODE> keeps it
up to date automatically. To propagate the marker into object code,
simply put it into a literal character string.
In C, this is done as follows:
<PRE>
static char rcsid[] = "$Id$";
</PRE>
<P>The command <CODE>ident</CODE> extracts such markers from any file,
in particular from object code.
<CODE>Ident</CODE> helps to find out which revisions of which modules
were used in a given program. It returns a complete and unambiguous
component list, from which a copy of the program can be reconstructed.
This facility is invaluable for program maintenance.
<P>There are several additional identification markers, one for each component
of $Id$. The marker
<PRE>
$Log$
</PRE>
<P>has a similar function. It accumulates
the log messages that are requested during check-in.
Thus, one can maintain the complete history of a revision directly inside it,
by enclosing it in a comment.
Figure 1 is an edited version of a log contained in revision 4.1 of
the file <TT>ci.c</TT>. The log appears at the beginning of the file,
and makes it easy to determine what the recent modifications were.
<PRE>
/*
* $Log: ci.c,v $
* Revision 4.1 1983/05/10 17:03:06 wft
* Added option -d and -w, and updated assignment of date, etc.
* to new delta. Added handling of default branches.
*
* Revision 3.9 1983/02/15 15:25:44 wft
* Added call to fastcopy() to copy remainder of RCS file.
*
* Revision 3.8 1983/01/14 15:34:05 wft
* Added ignoring of interrupts while new RCS file is renamed;
* avoids deletion of RCS files by interrupts.
*
* Revision 3.7 1982/12/10 16:09:20 wft
* Corrected checking of return code from diff.
* An RCS file now inherits its mode during the first ci from the
* working file, except that write permission is removed.
*/
</PRE>
<P ALIGN=CENTER>Figure 1. Log entries produced by the marker $Log$</P><P>Since revisions are stored in the form of differences, each log
message is physically stored once, independent of the number of
revisions present. Thus, the $Log$ marker incurs
negligible space overhead.
<A NAME="RevisionTree"></A>
<H2><A NAME="hd_10">The RCS Revision Tree</A></H2>
<P>RCS arranges revisions in an ancestral tree. The <CODE>ci</CODE>
command builds this tree; the auxiliary command <CODE>rcs</CODE> prunes
it. The tree has a root revision, normally numbered 1.1, and
successive revisions are numbered 1.2, 1.3, etc. The first field
of a revision number is called the <CODE>release number</CODE> and the
second one the <CODE>level number</CODE>. Unless given explicitly, the
<CODE>ci</CODE> command assigns a new revision number by incrementing
the level number of the previous revision. The release number
must be incremented explicitly, using the <CODE>-r</CODE> option of
<CODE>ci</CODE>. Assuming there are revisions 1.1, 1.2, and 1.3 in the
RCS file <TT>f.c,v</TT>, the command
<PRE>
ci -r2.1 f.c or ci -r2 f.c
</PRE>
<P>assigns the number 2.1 to the new revision. Later check-ins
without the <CODE>-r</CODE> option will assign the numbers 2.2, 2.3,
and so on. The release number should be incremented only at major
transition points in the development, for instance when a new
release of a software product has been completed.
<A NAME="Branches"></A>
<H3><A NAME="hd_11">When are branches needed?</A></H3>
<P>A young revision tree is slender: It consists of only one branch,
called the trunk. As the tree ages, side branches may form.
Branches are needed in the following 4 situations.
<OL>
<LI>Temporary fixes
<BR>
Suppose a tree has 5 revisions grouped in 2 releases, as
illustrated in Figure 2. Revision 1.3, the last one of release 1,
is in operation at customer sites, while release 2 is in active
development.
<BR><PRE>
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !---->! 1.2 !---->! 1.3 !---->! 2.1 !---->! 2.2 !--->>
+-----+ +-----+ +-----+ +-----+ +-----+
</PRE>
<P ALIGN=CENTER>Figure 2. A slender revision tree.</P><BR>Now imagine a customer requesting a fix of a problem in revision
1.3, although actual development has moved on to release 2. RCS
does not permit an extra revision to be spliced in between 1.3
and 2.1, since that would not reflect the actual development
history. Instead, create a branch at revision 1.3, and check in
the fix on that branch. The first branch starting at 1.3 has
number 1.3.1, and the revisions on that branch are numbered
1.3.1.1, 1.3.1.2, etc. The double numbering is needed to allow
for another branch at 1.3, say 1.3.2. Revisions on the second
branch would be numbered 1.3.2.1, 1.3.2.2, and so on. The
following steps create branch 1.3.1 and add revision 1.3.1.1:
<BR><BR><PRE>
co -r1.3 f.c -- check out revision 1.3
edit f.c -- change it
ci -r1.3.1 f.c -- check it in on branch 1.3.1
</PRE>
<BR><BR>This sequence of commands transforms the tree of Figure 2 into
the one in Figure 3. Note that it may be necessary to incorporate
the differences between 1.3 and 1.3.1.1 into a revision at level
2. The operation <CODE>rcsmerge</CODE> automates this process (see the
Appendix).
<BR><PRE>
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !---->! 1.2 !---->! 1.3 !---->! 2.1 !---->! 2.2 !--->>
+-----+ +-----+ +--+--+ +-----+ +-----+
!
! +---------+
+------->! 1.3.1.1 !---->>
+---------+
</PRE>
<P ALIGN=CENTER>Figure 3. A revision tree with one side branch</P><BR><LI>Distributed development and customer modifications
<BR>
Assume a situation as in Figure 2, where revision 1.3 is in
operation at several customer sites, while release 2 is in
development. Customer sites should use RCS to store the
distributed software. However, customer modifications should not
be placed on the same branch as the distributed source; instead,
they should be placed on a side branch. When the next software
distribution arrives, it should be appended to the trunk of the
customer's RCS file, and the customer can then merge the local
modifications back into the new release. In the above example, a
customer's RCS file would contain the following tree, assuming
that the customer has received revision 1.3, added his local
modifications as revision 1.3.1.1, then received revision 2.4,
and merged 2.4 and 1.3.1.1, resulting in 2.4.1.1.
<BR><PRE>
+-----+ +-----+
--->! 1.3 !---------------->! 2.4 !---->>
+--+--+ +---+-+
! !
! +---------+ ! +---------+
+---->! 1.3.1.1 ! +------>! 2.4.1.1 !
+---------+ +---------+
</PRE>
<P ALIGN=CENTER>Figure 4. A customer's revision tree with local modifications.</P><BR>This approach is actually practiced in the CSNET project, where
several universities and a company cooperate in developing a
national computer network.
<LI>Parallel development
<BR>
<P>Sometimes it is desirable to explore an alternate design or
a different implementation technique in parallel with the
main line development. Such development
should be carried out on a side branch.
The experimental changes may later be moved into the main line, or abandoned.
<LI>Conflicting updates
<BR>
<P>A common occurrence is that one programmer has checked out a
revision, but cannot complete the assignment for some reason. In
the meantime, another person must perform another modification
immediately. In that case, the second person should check-out
the same revision, modify it, and check it in on a side branch,
for later merging.
<P>Every node in a revision tree consists of the following
attributes: a revision number, a check-in date and time, the
author's identification, a log entry, a state and the actual
text. All these attributes are determined at the time the
revision is checked in. The state attribute indicates the status
of a revision. It is set automatically to `experimental' during
check-in. A revision can later be promoted to a higher status,
for example `stable' or `released'. The set of states is
user-defined.
</OL>
<A NAME="Deltas"></A>
<H3><A NAME="hd_12">Revisions are represented as deltas</A></H3>
<P>For conserving space, RCS stores revisions in the form of deltas,
i.e., as differences between revisions. The user interface
completely hides this fact.
<P>A delta is a sequence of edit commands that transforms one string
into another. The deltas employed by RCS are line-based, which
means that the only edit commands allowed are insertion and
deletion of lines. If a single character in a line is changed,
the edit scripts consider the entire line changed. The program
<CODE>diff</CODE> produces a small, line-based delta between pairs of
text files. A character-based edit script would take much longer
to compute, and would not be significantly shorter.
<P>Using deltas is a classical space-time tradeoff: deltas reduce
the space consumed, but increase access time. However, a version
control tool should impose as little delay as possible on
programmers. Excessive delays discourage the use of version
controls, or induce programmers to take shortcuts that compromise
system integrity. To gain reasonably fast access time for both
editing and compiling, RCS arranges deltas in the following way.
The most recent revision on the trunk is stored intact. All other
revisions on the trunk are stored as reverse deltas. A reverse
delta describes how to go backward in the development history: it
produces the desired revision if applied to the successor of that
revision. This implementation has the advantage that extraction
of the latest revision is a simple and fast copy operation.
Adding a new revision to the trunk is also fast: <CODE>ci</CODE> simply
adds the new revision intact, replaces the previous revision with
a reverse delta, and keeps the rest of the old deltas. Thus,
<CODE>ci</CODE> requires the computation of only one new delta.
<P>Branches need special treatment. The naive solution would be to
store complete copies for the tips of all branches. Clearly, this
approach would cost too much space. Instead, RCS uses
<CODE>forward</CODE> deltas for branches. Regenerating a revision on a
side branch proceeds as follows. First, extract the latest
revision on the trunk; secondly, apply reverse deltas until the
fork revision for the branch is obtained; thirdly, apply forward
deltas until the desired branch revision is reached. Figure 5
illustrates a tree with one side branch. Triangles pointing to
the left and right(with five exclamation marks) represent
reverse and forward deltas,
respectively.
<BR><PRE>
! ! ! ! !
+-----! +-----! +-----! +-----! +-----!
! 1.1 !---->! 1.2 !---->! 1.3 !---->! 2.1 !---->! 2.2 !--->>
+-----+ +-----! +--+--! +-----! +-----!
! ! ! ! ! !
!
! ! !
! +---------! +---------!
+->! 1.3.1.1 !---->! 1.3.1.2 !
+---------! +---------!
! !
</PRE>
<P ALIGN=CENTER>Figure 3. A revision tree with one side branch</P><BR><P>Although implementing fast check-out for the latest trunk
revision, this arrangement has the disadvantage that generation
of other revisions takes time proportional to the number of
deltas applied. For example, regenerating the branch tip in
Figure 5 requires application of five deltas (including the
initial one). Since usage statistics show that the latest trunk
revision is the one that is retrieved in 95 per cent of all cases
(see the section on usage statistics), biasing check-out time in
favor of that revision results in significant savings. However,
careful implementation of the delta application process is
necessary to provide low retrieval overhead for other revisions,
in particular for branch tips.
<P>There are several techniques for delta application. The naive one
is to pass each delta to a general-purpose text editor. A
prototype of RCS invoked the UNIX editor <CODE>ed</CODE> both for
applying deltas and for expanding the identification markers.
Although easy to implement, performance was poor, owing to the
high start-up costs and excess generality of <CODE>ed</CODE>. An
intermediate version of RCS used a special-purpose,
stream-oriented editor. This technique reduced the cost of
applying a delta to the cost of checking out the latest trunk
revision. The reason for this behavior is that each delta
application involves a complete pass over the preceding revision.
<P>However, there is a much better algorithm. Note that the deltas
are line oriented and that most of the work of a stream editor
involves copying unchanged lines from one revision to the next. A
faster algorithm avoids unnecessary copying of character strings
by using a <CODE>piece table</CODE>. A piece table is a one-dimensional
array, specifying how a given revision is <TT>pieced-together</TT>
from lines in the RCS file. Suppose piece table <CODE>PTr</CODE>
represents revision <CODE>r</CODE>. Then <CODE>PTr[i]</CODE> contains the
starting position of line <CODE>i</CODE> of revision <CODE>r</CODE>.
Application of the next delta transforms piece table <CODE>PTr</CODE>
into <CODE>PTr+1</CODE>. For instance, a delete command removes a
series of entries from the piece table. An insertion command
inserts new entries, moving the entries following the insertion
point further down the array. The inserted entries point to the
text lines in the delta. Thus, no I/O is involved except for
reading the delta itself. When all deltas have been applied to
the piece table, a sequential pass through the table looks up
each line in the RCS file and copies it to the output file,
updating identification markers at the same time. Of course, the
RCS file must permit random access, since the copied lines are
scattered throughout that file. Figure 6 illustrates an RCS file
with two revisions and the corresponding piece tables.
<P>The piece table approach has the property that the time for
applying a single delta is roughly determined by the size of the
delta, and not by the size of the revision. For example, if a
delta is 10 per cent of the size of a revision, then applying it
takes only 10 per cent of the time to generate the latest trunk
revision. (The stream editor would take 100 per cent.)
<P>There is an important alternative for representing deltas that
affects performance. <CODE>SCCS</CODE>, a precursor of RCS, uses
<CODE>interleaved</CODE> deltas. A file containing interleaved deltas
is partitioned into blocks of lines. Each block has a header that
specifies to which revision(s) the block belongs. The blocks are
sorted out in such a way that a single pass over the file can
pick up all the lines belonging to a given revision. Thus, the
regeneration time for all revisions is the same: all headers must
be inspected, and the associated blocks either copied or skipped.
As the number of revisions increases, the cost of retrieving any
revision is much higher than the cost of checking out the latest
trunk revision with reverse deltas. A detailed comparison of
<CODE>SCCS's</CODE> interleaved deltas and RCS's reverse deltas can be
found in Reference 4. This reference considers the version of RCS
with the stream editor only. The piece table method improves
performance further, so that RCS is always faster than SCCS,
except if 10 or more deltas are applied.
<P>Additional speed-up for both delta methods can be obtained by
caching the most recently generated revision, as has been
implemented in <CODE>DSEE</CODE> With caching, access time to
frequently used revisions can approach normal file access time,
at the cost of some additional space.
<A NAME="Controversial"></A>
<H2><A NAME="hd_13">Locking: A Controversial Issue</A></H2>
<P>The locking mechanism for RCS was difficult to design. The
problem and its solution are first presented in their <TT>pure</TT>
form, followed by a discussion of the complications caused by
<TT>real-world</TT> considerations.
<P>RCS must prevent two or more persons from depositing competing
changes of the same revision. Suppose two programmers check out
revision 2.4 and modify it. Programmer A checks in a revision
before programmer <B>B</B>. Unfortunately, programmer B has not seen
A's changes, so the effect is that A's changes are covered up by
B's deposit. A's changes are not lost since all revisions are
saved, but they are confined to a single revision<A HREF="#fn2">(2)</A><FN NAME="fn2">Note
that this problem is entirely different from the atomicity
problem. Atomicity means that concurrent update operations on the
same RCS file cannot be permitted, because that may result in
inconsistent data. Atomic updates are essential (and implemented
in RCS), but do not solve the conflict discussed here.</FN>.
<P>This conflict is prevented in RCS by locking. Whenever someone
intends to edit a revision (as opposed to reading or compiling
it), the revision should be checked out and locked, using the
<CODE>-l</CODE> option on <CODE>co</CODE>. On subsequent check-in, <CODE>ci</CODE>
tests the lock and then removes it. At most one programmer at a
time may lock a particular revision, and only this programmer may
check in the succeeding revision. Thus, while a revision is
locked, it is the exclusive responsibility of the locker.
<P>An important maxim for software tools like RCS is that they must
not stand in the way of making progress with a project. This
consideration leads to several weakenings of the locking
mechanism. First of all, even if a revision is locked, it can
still be checked out. This is necessary if other people wish to
compile or inspect the locked revision while the next one is in
preparation. The only operations they cannot do are to lock the
revision or to check in the succeeding one. Secondly, check-in
operations on other branches in the RCS file are still possible;
the locking of one revision does not affect any other revision.
Thirdly, revisions are occasionally locked for a long period of
time because a programmer is absent or otherwise unable to
complete the assignment. If another programmer has to make a
pressing change, there are the following three alternatives for
making progress:
<UL>
<LI>find out who is holding the lock and ask that person to release it;
<BR>
<LI>check out the locked revision, modify it, check it
<BR>
in on a branch, and merge the changes later;
<LI>break the lock. Breaking a lock leaves a highly visible
<BR>
trace, namely an electronic mail message that is sent
automatically to the holder of the lock, recording the breaker
and a commentary requested from him. Thus, breaking locks is
tolerated under certain circumstances, but will not go unnoticed.
Experience has shown that the automatic mail message attaches a
high enough stigma to lock breaking, such that programmers break
locks only in real emergencies, or when a co-worker resigns and
leaves locked revisions behind.
</UL>
<P>If an RCS file is private, i.e., when a programmer owns an RCS
file and does not expect anyone else to perform check-in
operations, locking is an unnecessary nuisance. In this case, the
<TT>strict locking feature</TT> discussed earlier may be disabled,
provided that file protection is set such that only the owner may
write the RCS file. This has the effect that only the owner can
check-in revisions, and that no lock is needed for doing so.
<P>As added protection, each RCS file contains an access list that
specifies the users who may execute update operations. If an
access list is empty, only normal UNIX file protection applies.
Thus, the access list is useful for restricting the set of people
who would otherwise have update permission. Just as with
locking, the access list has no effect on read-only operations
such as <CODE>co</CODE>. This approach is consistent with the UNIX
philosophy of openness, which contributes to a productive
software development environment.
<A NAME="Configuration"></A>
<H2><A NAME="hd_14">Configuration Management</A></H2>
<P>The preceding sections described how <CODE>RCS</CODE> 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. <CODE>RCS</CODE>, in conjunction with
<CODE>MAKE</CODE>, provides a number of facilities to effect a smooth
selection.
<A NAME="Functions"></A>
<H3><A NAME="hd_15">RCS Selection Functions</A></H3>
<UL>
<LI>Default selection
<BR>
During development, the usual selection criterion is to choose
the latest revision of all components. The <CODE>co</CODE> command
makes this selection by default. For example, the command
<PRE>
co *,v
</PRE>
<P>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.
<LI>Release based selection
<BR>
Specifying a release or branch number selects the latest revision
in that release or branch. For instance,
<PRE>
co -r2 *,v
</PRE>
<P>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.
<LI>State and author based selection
<BR>
If the highest level number within a given release number is not
the desired one, the state attribute can help. For example,
<PRE>
co -r2 -sReleased *,v
</PRE>
<P>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 <CODE>ci</CODE> or <CODE>rcs</CODE> commands.
Another alternative is to select a revision by its author, using
the <CODE>-w</CODE> option.
<LI>Date based selection
<BR>
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
<PRE>
co -d'March 4, 1:00 pm LT' *,v
</PRE>
<P>checks out all the components of that release, independent of the
numbering. The <CODE>-d</CODE> 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.
<LI>Name based selection
<BR>
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
<CODE>co</CODE> 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 <CODE>V3</CODE> is
bound to release number 2 in file <TT>s,v</TT>, and to revision
number 15.9 in <TT>t,v</TT>. Then the single command
<PRE>
co -rV3 s,v t,v
</PRE>
<P>retrieves the latest revision of release 2 from <TT>s,v</TT>, and
revision 15.9 from <TT>t,v</TT>. In a large system with many
modules, checking out all revisions with one command greatly
simplifies configuration management.
<P>Judicious use of symbolic revision numbers helps with organizing
large configurations.
<P>A special command, <CODE>rcsfreeze</CODE>, assigns a symbolic revision
number to a selected revision in every RCS file. <CODE>rcsfreeze</CODE>
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, <CODE>V3.5</CODE> in the above example would select
revision 2.5 in <TT>s,v</TT> and branch 15.9.5 in <TT>t,v</TT>.
<P>The options <CODE>-r</CODE>, <CODE>-s</CODE>, <CODE>-w</CODE> and <CODE>-d</CODE> 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.
</UL>
<A NAME="MAKERCS"></A>
<H3><A NAME="hd_16">Combining MAKE and RCS</A></H3>
<P>MAKE (<A HREF="#Feldman">Feldman</A>) 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.
<P>MAKE has been extended with an auto-checkout
feature<A HREF="#fn3">(3)</A><FN NAME="fn3">This auto-checkout extension is available only
in some versions of MAKE, e.g. GNU MAKE.</FN> for RCS.* 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
<CODE>RCS</CODE> 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.
<CODE>Rcsclean</CODE> can be used for that purpose.)
<P>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.
<P>Each programmer chooses a working directory and places into it a
symbolic link, named <CODE>RCS</CODE>, to the directory containing the
relevant RCS files. The symbolic link makes sure that <CODE>co</CODE>
and <CODE>ci</CODE> 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 <CODE>RCS</CODE>. 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.
<P>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.
<P>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
<CODE>rcsfreeze</CODE>, 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.
<A NAME="Statistics"></A>
<H2><A NAME="hd_17">Usage Statistics</A></H2>
<P>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.
<P>For the first experiment, the <CODE>ci</CODE> and <CODE>co</CODE> 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.
<PRE>
Oper. ! 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%)
<P ALIGN=CENTER>Table I. Statistics for <CODE>co</CODE> and <CODE>ci</CODE> operations</P></PRE>
<BR><BR><P>The first two lines show statistics for check-out and check-in;
the third line shows the combination. Recall that <CODE>ci</CODE>
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.
<P>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 <CODE>ci</CODE>,
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 <CODE>ci</CODE> 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.
<P>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 <CODE>co</CODE>.
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.)
<PRE>
!Total RCS! Total !Mean !Means size!Mean size!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 delta! ! ! ! ! !
<P ALIGN=CENTER>Table II. Statistics for RCS files</P></PRE>
<BR><BR>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.
<P>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(<A HREF="#Rochkind">Rochkind</A>) 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 (<A HREF="#Glasser">Glasser</A>) observed an
average of 7 revisions per group in a single, large project, but
provided no overhead figure. In his paper on DSEE , Leblang
(<A HREF="#Leblang">Leblang</A>) 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.
<P>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.
<A NAME="Survey"></A>
<H2><A NAME="hd_18">Survey of Version Control Tools</A></H2>
<P>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.
<P>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.
<P>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.
<P>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 <CODE>ci</CODE>.) 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 considers important, and keeps the
number of revisions manageable. IBM's CLEAR/CASTER (<A HREF="#Brown">Brown</A>),
AT&T's SCCS (<A HREF="#Rochkind">Rochkind</A>), CMU's SDC (<A HREF="#Habermann">Habermann</A>), and
DEC's CMS (<A HREF="#DEC">DEC</A>), are examples of version control systems
using this approach. CLEAR/CASTER maintains a data base of
programs, specifications, documentation and messages, using
deltas. Its goal is to provide control over the development
process from a management viewpoint. SCCS stores multiple
revisions of source text in an ancestral tree, records a log
entry for each revision, provides access control, and has
facilities for uniquely identifying each revision. An efficient
delta technique reduces the space consumed by each revision
group. SDC is much simpler than SCCS because it stores not more
than two revisions. However, it maintains a complete log for all
old revisions, some of which may be on back-up tape. CMS, like
SCCS, manages tree-structured revision groups, but offers no
identification mechanism.
<P>Tools for dealing with configurations are still in a state of
flux. SCCS, SDC and CMS can be combined with MAKE or MAKE-like
programs. Since flexible selection rules are missing from all
these tools, it is sometimes difficult to specify precisely which
revision of each group should be passed to MAKE for building a
desired configuration. The Xerox Cedar system (<A HREF="#Lampson">Lampson</A>)
provides a `System Modeller' that can rebuild a configuration
from an arbitrary set of module revisions. The revisions of a
module are only distinguished by creation time, and there is no
tool for managing groups. Since the selection rules are
primitive, the System Modeller appears to be somewhat tedious to
use. Apollo's DSEE (<A HREF="#Leblang">Leblang</A>) is a sophisticated software
engineering environment. It manages revision groups in a way
similar to SCCS and CMS. Configurations are built using
`configuration threads'. A configuration thread states which
revision of each group named in a configuration should be chosen.
A configuration thread may contain dynamic specifiers (e.g.,
`choose the revisions I am currently working on, and the most
recent revisions otherwise'), which are bound automatically at
build time. It also provides a notification mechanism for
alerting maintainers about the need to rebuild a system after a
change.
<P>RCS is based on a general model for describing
multi-version/multi-configuration systems (<A HREF="#Tichy1">Tichy1</A>). The
model describes systems using AND/OR graphs, where AND nodes
represent configurations, and OR nodes represent version groups.
The model gives rise to a suit of selection rules for composing
configurations, almost all of which are implemented in RCS. The
revisions selected by RCS are passed to MAKE for configuration
building. Revision group management is modelled after SCCS. RCS
retains SCCS's best features, but offers a significantly simpler
user interface, flexible selection rules, adequate integration
with MAKE and improved identification. A detailed comparison of
RCS and SCCS appears in Reference 4.
<P>An important component of all revision control systems is a
program for computing deltas. SCCS and RCS use the program
<CODE>diff</CODE> (<A HREF="#Rochkind">Rochkind</A>), which first computes the longest
common substring of two revisions, and then produces the delta
from that substring. The delta is simply an edit script
consisting of deletion and insertion commands that generate one
revision from the other.
<P>A delta based on a longest common substring is not necessarily
minimal, because it does not take advantage of crossing block
moves. Crossing block moves arise if two or more blocks of lines
(e.g., procedures) appear in a different order in two revisions.
An edit script derived from a longest common substring first
deletes the shorter of the two blocks, and then reinserts it.
Heckel (<A HREF="#Heckel">Heckel</A>) proposed an algorithm for detecting block
moves, but since the algorithm is based on heuristics, there are
conditions under which the generated delta is far from minimal.
DSEE uses this algorithm combined with blank compression,
apparently with satisfactory overall results. A new algorithm
that is guaranteed to produce a minimal delta based on block
moves appears in Reference 13. A future release of RCS will use
this algorithm.
<PRE>
<CODE>Acknowledgements</CODE>:<BR>
Many people have helped make RCS a success by contributed
criticisms, suggestions, corrections, and even whole new commands
(including manual pages). The list of people is too long to be
reproduced here, but my sincere thanks for their help and
goodwill goes to all of them.
</PRE>
<A NAME="rcsIntroduction"></A>
<H1><A NAME="hd_19">Introduction to RCS commands</A></H1>
<A NAME="cp_Introduction"></A>
<A NAME="cp_RCS commands"></A>
<UL>
<LI><A HREF="#rcsintroDesc">Introduction to <CODE>RCS</CODE>.</A>
<LI><A HREF="#rcsintroFunc">Functions of <CODE>RCS</CODE>.</A>
<LI><A HREF="#rcsintroStart">Getting started with <CODE>RCS</CODE>.</A>
<LI><A HREF="#rcsintroAutoIdent">Automatic identification.</A>
</UL>
<A NAME="rcsintroDesc"></A>
<H2><A NAME="hd_20">Description</A></H2>
<P>The Revision Control System (RCS) manages multiple revisions
of files. RCS automates the storing, retrieval,
logging, identification, and merging of revisions. RCS is
useful for text that is revised frequently, for example
programs, documentation, graphics, papers, and form letters.
<P>The basic user interface is extremely simple. The novice
only needs to learn two commands: <CODE>ci</CODE> and <CODE>co</CODE>.
<CODE>ci</CODE>, short for "check in", deposits the contents of a file into
an archival file called an RCS file.
An RCS file contains all revisions of a particular file.
<CODE>co</CODE>, short for "check out",
retrieves revisions from an RCS file.
<A NAME="rcsintroFunc"></A>
<H2><A NAME="hd_21">Functions of RCS</A></H2>
<UL>
<LI>Store and retrieve multiple revisions of text. RCS saves
<BR>
all old revisions in a space efficient way. Changes no longer
destroy the original, because the previous revisions remain
accessible. Revisions can be retrieved according to ranges
of revision numbers, symbolic names, dates, authors, and
states.
<LI>Maintain a complete history of changes. RCS logs all
<BR>
changes automatically. Besides the text of each revision,
RCS stores the author, the date and time of check-in, and a log
message summarizing the change. The logging makes it easy to
find out what happened to a module, without having to compare
source listings or having to track down colleagues.
<LI>Resolve access conflicts. When two or more programmers
<BR>
wish to modify the same revision, RCS alerts the programmers
and prevents one modification from corrupting the other.
<LI>Maintain a tree of revisions. RCS can maintain
<BR>
separate lines of development for each module. It stores a
tree structure that represents the ancestral relationships among
revisions.
<LI>Merge revisions and resolve conflicts. Two separate
<BR>
lines of development of a module can be coalesced by merging.
If the revisions to be merged affect the same sections of
code, RCS alerts the user about the overlapping changes.
<LI>Control releases and configurations. Revisions can be
<BR>
assigned symbolic names and marked as released, stable,
experimental, etc. With these facilities, configurations of
modules can be described simply and directly.
<LI>Automatically identify each revision with name,
<BR>
revision number, creation time, author, etc. The
identification is like a stamp that can be embedded at an
appropriate place in the text of a revision. The identification
makes it simple to determine which revisions of which
modules make up a given configuration.
<LI>Minimize secondary storage. RCS needs little extra space
<BR>
for the revisions (only the differences). If intermediate
revisions are deleted, the corresponding deltas are compressed
accordingly.
</UL>
<A NAME="rcsintroStart"></A>
<H2><A NAME="hd_22">Getting Started with RCS</A></H2>
Suppose you have a file <TT>f.c</TT> that you wish to put under
control of RCS. If you have not already done so, make an
RCS directory with the command
<PRE>
mkdir RCS
</PRE>
<P>Then invoke the check-in command
<PRE>
ci f.c
</PRE>
<P>This command creates an RCS file in the RCS directory,
stores <TT>f.c</TT> into it as revision 1.1, and deletes
<TT>f.c</TT>. It also asks you for a description.
The description should be a synopsis of the contents
of the file. All later check-in commands will
ask you for a log entry, which should summarize the
changes that you made.
<P>Files in the RCS directory are called RCS files; the others
are called working files. To get back the working
file f.c in the previous example, use the check-out command
<PRE>
co f.c
</PRE>
<P>This command extracts the latest revision from the RCS
file and writes it into <TT>f.c</TT>. If you want to edit <TT>f.c</TT>,
you must lock it as you check it out with the command
<PRE>
co -l f.c
</PRE>
<P>You can now edit <TT>f.c.</TT>
<P>Suppose after some editing you want to know what changes
that you have made. The command
<PRE>
rcsdiff f.c
</PRE>
<P>tells you the difference between the most recently
checked-in version and the working file. You can check
the file back in by invoking
<PRE>
ci f.c
</PRE>
<P>This increments the revision number properly.
<P>If ci complains with the message
<PRE>
ci error: no lock set by <CODE>your name</CODE>
</PRE>
<P>then you have tried to check in a file even though you did
not lock it when you checked it out. Of course, it is too
late now to do the check-out with locking, because another
check-out would overwrite your modifications. Instead,
invoke
<PRE>
rcs -l f.c
</PRE>
<P>This command will lock the latest revision for you, unless
somebody else got ahead of you already. In this case,
you'll have to negotiate with that person.
<P>Locking assures that you, and only you, can check in the
next update, and avoids nasty problems if several people
work on the same file. Even if a revision is locked, it
can still be checked out for reading, compiling, etc. All
that locking prevents is a <CODE>check-in</CODE> by anybody but the
locker.
<P>If your RCS file is private, i.e., if you are the only
person who is going to deposit revisions into it, strict
locking is not needed and you can turn it off. If strict
locking is turned off, the owner of the RCS file need not
have a lock for check-in; all others still do. Turning
strict locking off and on is done with the commands
<PRE>
rcs -U f.c and rcs -L f.c
</PRE>
<P>If you don't want to clutter your working directory with
RCS files, create a subdirectory called RCS in your work-
ing directory, and move all your RCS files there. RCS
commands will look first into that directory to find
needed files. All the commands discussed above will still
work, without any modification. (Actually, pairs of RCS
and working files can be specified in three ways: (a) both
are given, (b) only the working file is given, (c) only
the RCS file is given. Both RCS and working files may
have arbitrary path prefixes; RCS commands pair them up
intelligently.)
<P>To avoid the deletion of the working file during check-in
(in case you want to continue editing or compiling),
invoke
<PRE>
ci -l f.c or ci -u f.c
</PRE>
<P>These commands check in <TT>f.c</TT> as usual, but perform an
implicit check-out. The first form also locks the checked
in revision, the second one doesn't. Thus, these options
save you one check-out operation. The first form is useful
if you want to continue editing, the second one if you
just want to read the file. Both update the identification
markers in your working file (see below).
<P>You can give ci the number you want assigned to a checked
in revision. Assume all your revisions were numbered 1.1,
1.2, 1.3, etc., and you would like to start release 2.
The command
<PRE>
ci -r2 f.c or ci -r2.1 f.c
</PRE>
<P>assigns the number 2.1 to the new revision. From then on,
ci will number the subsequent revisions with 2.2, 2.3,
etc. The corresponding co commands
<PRE>
co -r2 f.c and co -r2.1 f.c
</PRE>
<P>retrieve the latest revision numbered 2.<CODE>x</CODE> and the revision
2.1, respectively. co without a revision number selects
the latest revision on the <CODE>trunk</CODE>, i.e. the highest revision
with a number consisting of two fields. Numbers with
more than two fields are needed for branches. For example,
to start a branch at revision 1.3, invoke
<PRE>
ci -r1.3.1 f.c
</PRE>
<P>This command starts a branch numbered 1 at revision 1.3,
and assigns the number 1.3.1.1 to the new revision. For
more information about branches, see <A HREF="#rcsOptb">rcsOptb</A>.
<A NAME="rcsintroAutoIdent"></A>
<H2><A NAME="hd_23">Automatic Identification</A></H2>
<P>RCS can put special strings for identification into your
source and object code. To obtain such identification,
place the marker
<PRE>
$Id$
</PRE>
<P>into your text, for instance inside a comment. RCS will
replace this marker with a string of the form
<PRE>
$Id: filename revision date time author state $
</PRE>
<P>With such a marker on the first page of each module, you
can always see with which revision you are working. RCS
keeps the markers up to date automatically. To propagate
the markers into your object code, simply put them into
literal character strings. In C, this is done as follows:
<PRE>
static char rcsid[] = "$Id$";
</PRE>
<P>The command ident extracts such markers from any file,
even object code and dumps. Thus, ident lets you find out
which revisions of which modules were used in a given program.
<P>You may also find it useful to put the marker $Log$ into
your text, inside a comment. This marker accumulates the
log messages that are requested during check-in. Thus,
you can maintain the complete history of your file
directly inside it. There are several additional identification
markers; see <A HREF="#coKeyword">coKeyword</A> for details.
<A NAME="Synopsis"></A>
<H1><A NAME="hd_24">Synopsis of RCS Operations</A></H1>
<UL>
<LI>ci -- check in revisions
<BR>
<CODE>Ci</CODE> stores the contents of a working file into the
corresponding RCS file as a new revision.
If the RCS file doesn't exist, <CODE>ci</CODE> creates it.
<CODE>Ci</CODE> removes the working file, unless one of the options
<CODE>-u</CODE> or <CODE>-l</CODE> is present.
For each check-in, <CODE>ci</CODE> asks for a commentary
describing the changes relative to the previous revision.
<P><CODE>Ci</CODE> assigns the revision number given by the <CODE>-r</CODE> option;
if that option is missing, it derives the number from the
lock held by the user; if there is no lock and locking is not strict,
<CODE>ci</CODE> increments the number of the latest revision on the trunk.
A side branch can only be started by explicitly specifying its
number with the <CODE>-r</CODE> option during check-in.
<P><CODE>Ci</CODE> also determines whether the revision to be checked in is
different from the previous one, and asks whether to proceed if not.
This facility simplifies check-in operations for large systems,
because one need not remember which files were changed.
<P>The option <CODE>-k</CODE> searches the checked in file for identification
markers containing the attributes
revision number, check-in date, author and state, and assigns these
to the new revision rather than computing them. This option is
useful for software distribution: Recipients of distributed software
using RCS should check in updates with the <CODE>-k</CODE> option.
This convention guarantees that revision numbers, check-in dates,
etc., are the same at all sites.
<LI>co -- check out revisions
<BR>
<CODE>Co</CODE> retrieves revisions according to revision number,
date, author and state attributes. It either places the revision
into the working file, or prints it on the standard output.
<CODE>Co</CODE> always expands the identification markers.
<LI>ident -- extract identification markers
<BR>
<CODE>Ident</CODE> extracts the identification markers expanded by <CODE>co</CODE>
from any file and prints them.
<LI>rcs -- change RCS file attributes
<BR>
<CODE>Rcs</CODE>is an administrative operation that changes access lists,
locks, unlocks, breaks locks, toggles the strict-locking feature,
sets state attributes and symbolic revision numbers, changes the
description, and deletes revisions. A revision can
only be deleted if it is not the fork of a side branch.
<LI>rcsclean -- clean working directory
<BR>
<CODE>Rcsclean</CODE> removes working files that were checked out but never changed.
<A HREF="#fn4">(4)</A><FN NAME="fn4">The <CODE>rcsclean</CODE> and <CODE>rcsfreeze</CODE> commands are optional
and are not always installed.</FN>
<LI>rcsdiff -- compare revisions
<BR>
<CODE>Rcsdiff</CODE> compares two revisions and prints their
difference, using the UNIX tool <CODE>diff</CODE>.
One of the revisions compared may be checked out.
This command is useful for finding out about changes.
<LI>rcsfreeze -- freeze a configuration
<BR>
<CODE>Rcsfreeze</CODE> assigns the same symbolic revision number
to a given revision in all RCS files.
This command is useful for accurately recording a configuration.
<LI>rcsmerge -- merge revisions
<BR>
<CODE>Rcsmerge</CODE> merges two revisions, <CODE>rev1</CODE> and <CODE>rev2</CODE>,
with respect to a common ancestor.
A 3-way file comparison determines the segments of lines that
are (a) the same in all three revisions, or (b) the same in 2 revisions,
or (c) different in all three. For all segments of type (b) where
<CODE>rev1</CODE> is the differing revision,
the segment in <CODE>rev1</CODE> replaces the corresponding segment of <CODE>rev2</CODE>.
Type (c) indicates an overlapping change, is flagged as an error, and requires user
intervention to select the correct alternative.
<LI>rlog -- read log messages
<BR>
<CODE>Rlog</CODE> prints the log messages and other information in an RCS file.
</UL>
<A NAME="CheckIn"></A>
<H1><A NAME="hd_25">ci -- check in RCS revisions</A></H1>
<A NAME="cp_ci"></A>
<A NAME="cp_check in"></A>
<UL>
<LI><A HREF="#ciIntro">Introduction to <CODE>ci</CODE>.</A>
<LI><A HREF="#ciOptions">command line options of <CODE>ci</CODE>.</A>
<LI><A HREF="#ciFileNaming">File naming.</A>
<LI><A HREF="#ciExamples">Examples.</A>
<LI><A HREF="#ciFileModes">File modes.</A>
<LI><A HREF="#ciFiles">Files.</A>
<LI><A HREF="#setuid use">Using of uid.</A>
<LI><A HREF="#ciEnv">Environment which can change the behaviour of <CODE>ci</CODE> and other RCS commands.</A>
<LI><A HREF="#ciDiag">Diagnostic output of <CODE>ci</CODE>.</A>
</UL>
<A NAME="ciIntro"></A>
<H2><A NAME="hd_26">ci description</A></H2>
<CODE>ci</CODE> stores new revisions into RCS files. Each pathname
matching an RCS suffix is taken to be an RCS file. All others are
assumed to be working files containing new revisions. <CODE>ci</CODE>
deposits the contents of each working file into the corresponding
RCS file. If only a working file is given, <CODE>ci</CODE> tries to
find the corresponding RCS file in an RCS subdirectory and then
in the working file's directory. For more details, See <A HREF="#ciFileNaming">ciFileNaming</A>
below.
<P>For <CODE>ci</CODE> to work, the caller's login must be on the access
list, except if the access list is empty or the caller is the
superuser or the owner of the file. To append a new revision to
an existing branch, the tip revision on that branch must be
locked by the caller. Otherwise, only a new branch can be
created. This restriction is not enforced for the owner of the
file if non-strict locking is used (see <A HREF="#rcs">rcs</A>). A lock held
by someone else can be broken with the <CODE>rcs</CODE> command.
<P>Unless the <CODE>-f</CODE> option is given, <CODE>ci</CODE> checks whether
the revision to be deposited differs from the preceding one. If
not, instead of creating a new revision <CODE>ci</CODE> reverts to the
preceding one. To revert, ordinary <CODE>ci</CODE> removes the working
file and any lock; <CODE>ci -l</CODE> keeps and <CODE>ci -u</CODE>
removes any lock, and then they both generate a new working file
much as if <CODE>co -l</CODE> or <CODE>co -u</CODE> had been applied to
the preceding revision. When reverting, any <CODE>-n</CODE> and
<CODE>-s</CODE> options apply to the preceding revision.
<P>For each revision deposited, <CODE>ci</CODE> prompts for a log message.
The log message should summarize the change and must be
terminated by end-of-file or by a line containing <CODE>.</CODE> by
itself. If several files are checked in <CODE>ci</CODE> asks whether to
reuse the previous log message. If the standard input is not a
terminal, <CODE>ci</CODE> suppresses the prompt and uses the same log
message for all files(Option <CODE>-m</CODE> of <CODE>ci</CODE>, <A HREF="#ciOptm">ciOptm</A>).
<P>If the RCS file does not exist, <CODE>ci</CODE> creates it and deposits
the contents of the working file as the initial revision (default
number: <CODE>1.1</CODE> ). The access list is initialized to empty.
Instead of the log message,
<CODE>ci</CODE> requests descriptive text
(Option <CODE>-t</CODE> of <CODE>ci</CODE>, <A HREF="#ciOptt">ciOptt</A>)
below).
<P>The number <CODE>rev</CODE> of the deposited revision can be given by any
of the options <CODE>-f</CODE>, <CODE>-i</CODE>, <CODE>-I</CODE>, <CODE>-j</CODE>,
<CODE>-k</CODE>, <CODE>-l</CODE>, <CODE>-M</CODE>, <CODE>-q</CODE>, <CODE>-r</CODE> or <CODE>-u</CODE>
<CODE>rev</CODE> can be symbolic, numeric, or mixed.
Symbolic names in
<CODE>rev</CODE> must already be defined;
see the Option <CODE>-n</CODE> (<A HREF="#ciOptn">ciOptn</A>) and <CODE>-N</CODE> (<A HREF="#ciOptNu">ciOptNu</A>)
options for assigning names during checkin.
<P>If <CODE>rev</CODE> is <CODE>$</CODE>, <CODE>ci</CODE> determines the revision
number from keyword values in the working file.
<P>If <CODE>rev</CODE> begins with a period, then the default branch
(normally the trunk) is prepended to it. If <CODE>rev</CODE> is a
branch number followed by a period, then the latest revision on
that branch is used.
<P>If <CODE>rev</CODE> is a revision number, it must be higher than the
latest one on the branch to which <CODE>rev</CODE> belongs, or must
start a new branch.
<P>If <CODE>rev</CODE> is a branch rather than a revision number, the new
revision is appended to that branch. The level number is
obtained by incrementing the tip revision number of that branch.
If <CODE>rev</CODE> indicates a non-existing branch, that branch is
created with the initial revision numbered <CODE>rev .1.</CODE>
<P>If <CODE>rev</CODE> is omitted, <CODE>ci</CODE> tries to derive the new
revision number from the caller's last lock. If the caller has
locked the tip revision of a branch, the new revision is appended
to that branch. The new revision number is obtained by
incrementing the tip revision number. If the caller locked a
non-tip revision, a new branch is started at that revision by
incrementing the highest branch number at that revision. The
default initial branch and level numbers are <CODE>1.</CODE>.
<P>If <CODE>rev</CODE> is omitted and the caller has no lock, but owns the
file and locking is not set to <CODE>strict</CODE>, then the revision
is appended to the default branch (normally the trunk; see the
option <CODE>-b</CODE> of <CODE>rcs</CODE> <A HREF="#rcsOptb">rcsOptb</A>).
<P>Exception: On the trunk, revisions can be appended to the end, but
not inserted.
<A NAME="ciOptions"></A>
<H2><A NAME="hd_33">Command line options of ci</A></H2>
<P>Overview off all options which can be given to
<P><CODE>Synopsis</CODE>: ci [options] file ···
<P><CODE>ci</CODE>.
<UL>
<LI><A HREF="#ciOptr">-r Revision</A>
<LI><A HREF="#ciOptl">-l lock a revision.</A>
<LI><A HREF="#ciOptu">-u unlock a revision.</A>
<LI><A HREF="#ciOptf">-f force a deposit.</A>
<LI><A HREF="#ciOptk">-k search for keyword values.</A>
<LI><A HREF="#ciOptq">-q quiet mode</A>
<LI><A HREF="#ciOpti">-i initial</A>
<LI><A HREF="#ciOptj">-j just check in</A>
<LI><A HREF="#ciOptIu">-I interacitve mode</A>
<LI><A HREF="#ciOptd">-d date</A>
<LI><A HREF="#ciOptMu">-M</A>
<LI><A HREF="#ciOptm">-m log message</A>
<LI><A HREF="#ciOptn">-n symbolic name</A>
<LI><A HREF="#ciOptNu">-N replace an existing symbolic name</A>
<LI><A HREF="#ciOpts">-s set state</A>
<LI><A HREF="#ciOptt">-t discription</A>
<LI><A HREF="#ciOptTu">-T modification time</A>
<LI><A HREF="#ciOptw">-w login</A>
<LI><A HREF="#ciOptV">-V Version of RCS; Emulate RCS Version</A>
<LI><A HREF="#ciOptx">-x Suffixes</A>
<LI><A HREF="#ciOptz">-z Time zoone for output.</A>
</UL>
<A NAME="ciOptr"></A>
<H3><A NAME="hd_109">Check in revision</A></H3>
<A NAME="cp_-r"></A>
<A NAME="cp_revision"></A>
<DL><DT>-r<TT>rev</TT>
<BR>
<DD>
Check in revision <B>rev</B>.
<DT>-r
<BR>
<DD>The bare <CODE>-r</CODE> option (without any revision) has an unusual
meaning in <CODE>ci</CODE>. With other RCS commands, a bare <CODE>-r</CODE>
option specifies the most recent revision on the default branch,
but with <CODE>ci</CODE>, a bare <CODE>-r</CODE> option reestablishes the
default behavior of releasing a lock and removing the working
file, and is used to override any default <CODE>-l</CODE> or <CODE>-u</CODE>
options established by shell aliases or scripts.
</DL>
<A NAME="ciOptl"></A>
<H3><A NAME="hd_110">lock a revision</A></H3>
<A NAME="cp_-l"></A>
<A NAME="cp_lock a revision"></A>
<DL><DT>-l[<TT>rev</TT>]
<BR>
<DD>
works like <CODE>-r</CODE>, except it performs an additional
<CODE>co-l</CODE> for the deposited revision. Thus, the
deposited revision is immediately checked out again and
locked. This is useful for saving a revision although
one wants to continue editing it after the checkin.
</DL>
<A NAME="ciOptu"></A>
<H3><A NAME="hd_111">unlock a revision</A></H3>
<A NAME="cp_-u"></A>
<A NAME="cp_unlock a revision"></A>
<DL><DT>-u[<TT>rev</TT>]
<BR>
<DD>
works like <CODE>-l</CODE>, except that the deposited revision is not
locked. This lets one read the working file immediately after
checkin.
<P>The <CODE>-l</CODE>, bare <CODE>-r</CODE>, and <CODE>-u</CODE> options are mutually
exclusive and silently override each other. For example, <CODE>ci
-u -r</CODE> is equivalent to <CODE>ci -r</CODE> because bare <CODE>-r</CODE>
overrides <CODE>-u</CODE>.
</DL>
<A NAME="ciOptf"></A>
<H3><A NAME="hd_112">force a deposit</A></H3>
<A NAME="cp_-f"></A>
<A NAME="cp_force a deposit"></A>
<DL><DT>-f[<TT>rev</TT>]
<BR>
<DD>
forces a deposit; the new revision is deposited even it is not
different from the preceding one.
</DL>
<A NAME="ciOptk"></A>
<H3><A NAME="hd_113">keyword values</A></H3>
<A NAME="cp_-k"></A>
<A NAME="cp_keyword values"></A>
<DL><DT>-k[<TT>rev</TT>]
<BR>
<DD>
searches the working file for keyword values to determine its
revision number, creation date, state, and author (see
<A HREF="#CheckOut">CheckOut</A>), and assigns these values to the deposited
revision, rather than computing them locally. It also generates a
default login message noting the login of the caller and the
actual checkin date. This option is useful for software
distribution. A revision that is sent to several sites should be
checked in with the <CODE>-k</CODE> option at these sites to preserve
the original number, date, author, and state. The extracted
keyword values and the default log message can be overridden with
the options <CODE>-d</CODE>, <CODE>-m</CODE>, <CODE>-s</CODE>, <CODE>-w</CODE>, and any
option that carries a revision number.
</DL>
<A NAME="ciOptq"></A>
<H3><A NAME="hd_114">quiet</A></H3>
<A NAME="cp_-q"></A>
<A NAME="cp_quiet"></A>
<A NAME="cp_diagnostic"></A>
<DL><DT>-q[<TT>rev</TT>]
<BR>
<DD>
quiet mode; diagnostic output is not printed. A revision that is
not different from the preceding one is not deposited, unless
<CODE>-f</CODE> is given.
</DL>
<A NAME="ciOpti"></A>
<H3><A NAME="hd_115">initial check in</A></H3>
<A NAME="cp_-i"></A>
<A NAME="cp_initial checkin"></A>
<DL><DT>-i[<TT>rev</TT>]
<BR>
<DD>
initial checkin; report an error if the RCS file already exists.
This avoids race conditions in certain applications.
</DL>
<A NAME="ciOptj"></A>
<H3><A NAME="hd_116">just check in</A></H3>
<A NAME="cp_-j"></A>
<A NAME="cp_just checkin"></A>
<DL><DT>-j[<TT>rev</TT>]
<BR>
<DD>
just checkin and do not initialize;
report an error if the RCS file does not already exist.
</DL>
<A NAME="ciOptIu"></A>
<H3><A NAME="hd_117">interactive mode</A></H3>
<A NAME="cp_-I"></A>
<A NAME="cp_interactive mode"></A>
<A NAME="cp_interactive"></A>
<DL><DT>-I[<TT>rev</TT>]
<BR>
<DD>
interactive mode; the user is prompted and questioned
even if the standard input is not a terminal.
</DL>
<A NAME="ciOptd"></A>
<H3><A NAME="hd_118">date</A></H3>
<A NAME="cp_-d"></A>
<A NAME="cp_date"></A>
<DL><DT>-d[<TT>date</TT>]
<BR>
<DD>
uses <CODE>date</CODE> for the checkin date and time. The <CODE>date</CODE>
is specified in free format as explained in <CODE>co</CODE> (See <A HREF="#CheckOut">CheckOut</A>).
This is useful for lying about the checkin date, and for <CODE>-k</CODE> if
no date is available. If <CODE>date</CODE> is empty, the working file's
time of last modification is used.
</DL>
<A NAME="ciOptMu"></A>
<H3><A NAME="hd_119">modification time</A></H3>
<A NAME="cp_-M"></A>
<A NAME="cp_modification time"></A>
<DL><DT>-M[<TT>rev</TT>]
<BR>
<DD>
Set the modification time on any new working file to be the date
of the retrieved revision. For example, <CODE>ci -d -M -u f</CODE> does
not alter <TT>f</TT> 's modification time, even if <TT>f</TT>'s
contents change due to keyword substitution. Use this option with
care; it can confuse <CODE>MAKE</CODE>.
</DL>
<A NAME="ciOptm"></A>
<H3><A NAME="hd_105">log message</A></H3>
<A NAME="cp_-m"></A>
<A NAME="cp_log message"></A>
<DL><DT>-m[<TT>msg</TT>]
<BR>
<DD>
uses the string <CODE>msg</CODE> as the log message for all revisions
checked in. By convention, log messages that start with <CODE>#</CODE>
are comments and are ignored by programs like GNU Emacs's
<CODE>vc</CODE> package. Also, log messages that start with
<CODE>{ clumpname }</CODE> (followed by white space) are meant to be
clumped together if possible, even if they are associated with
different files; the <CODE>{ clumpname }</CODE> label is used only
for clumping, and is not considered to be part of the log message
itself.
</DL>
<A NAME="ciOptn"></A>
<H3><A NAME="hd_107">symbolic name</A></H3>
<A NAME="cp_-n"></A>
<A NAME="cp_symbolic name"></A>
<A NAME="cp_tag"></A>
<DL><DT>-n[<TT>name</TT>]
<BR>
<DD>
assigns the symbolic name <CODE>name</CODE> to the number of the
checked-in revision. <CODE>ci</CODE> prints an error message if
<CODE>name</CODE> is already assigned to another number.
</DL>
<A NAME="ciOptNu"></A>
<H3><A NAME="hd_108">replace symbolic name</A></H3>
<A NAME="cp_-N"></A>
<A NAME="cp_override symbolic name"></A>
<DL><DT>-N[<TT>name</TT>]
<BR>
<DD>
same as <CODE>-n</CODE>, except that it overrides a previous assignment
of <CODE>name</CODE>.
</DL>
<A NAME="ciOpts"></A>
<H3><A NAME="hd_120">states</A></H3>
<A NAME="cp_-s"></A>
<A NAME="cp_states"></A>
<DL><DT>-s[<TT>state</TT>]
<BR>
<DD>
sets the state of the checked-in revision to the identifier
<CODE>state</CODE>. The default state is <CODE>Exp</CODE>.
</DL>
<A NAME="ciOptt"></A>
<H3><A NAME="hd_106">description</A></H3>
<A NAME="cp_-t"></A>
<A NAME="cp_-t-"></A>
<A NAME="cp_description"></A>
<DL><DT>-t<TT>file</TT>
<BR>
<DD>
writes descriptive text from the contents of the named
<TT>file</TT>
into the RCS file, deleting the existing text.
The <TT>file</TT> cannot begin with <CODE>-</CODE>.
<DT>-t-<TT>string</TT>
<BR>
<DD>Write descriptive text from the <TT>string</TT> into the RCS file,
deleting the existing text.
<P>The <CODE>-t</CODE> option, in both its forms, has effect only during
an initial checkin; it is silently ignored otherwise.
<P>During the initial checkin, if <CODE>-t</CODE> is not given, <CODE>ci</CODE>
obtains the text from standard input, terminated by end-of-file
or by a line containing <CODE>.</CODE> by itself. The user is prompted
for the text if interaction is possible; see optiom <CODE>-I</CODE>
of <CODE>ci</CODE>(See <A HREF="#ciOptIu">ciOptIu</A>).
<P>For backward compatibility with older versions of RCS, a bare
<CODE>-t</CODE> option is ignored.
</DL>
<A NAME="ciOptTu"></A>
<H3><A NAME="hd_121">modification time</A></H3>
<A NAME="cp_-T"></A>
<A NAME="cp_modification time"></A>
<DL><DT>-T
<BR>
<DD>
Set the RCS file's modification time to the new revision's time
if the former precedes the latter and there is a new revision;
preserve the RCS file's modification time otherwise. If you have
locked a revision, <CODE>ci</CODE> usually updates the RCs file's
modification time to the current time, because the lock is stored
in the RCS file and removing the lock requires changing the RCS
file. This can create an RCS file newer than the working file in
one of two ways: first, <CODE>ci -M</CODE> can create a working file
with a date before the current time; second, when reverting to
the previous revision the RCS file can change while the working
file remains unchanged. These two cases can cause excessive
recompilation caused by a <CODE>MAKE</CODE> dependency of the working
file on the RCS file. The <CODE>-T</CODE> option inhibits this
recompilation by lying about the RCS file's date. Use this option
with care; it can suppress recompilation even when a checkin of
one working file should affect another working file associated
with the same RCS file. For example, suppose the RCS file's time
is 01:00, the (changed) working file's time is 02:00, some other
copy of the working file has a time of 03:00, and the current
time is 04:00. Then <CODE>ci -d -T</CODE> sets the RCS file's time to
02:00 instead of the usual 04:00; this causes <CODE>MAKE</CODE> to
think (incorrectly) that the other copy is newer than the RCs
file.
</DL>
<A NAME="ciOptw"></A>
<H3><A NAME="hd_122">login</A></H3>
<A NAME="cp_-w"></A>
<A NAME="cp_login"></A>
<DL><DT>-w<TT>login</TT>
<BR>
<DD>
uses <CODE>login</CODE> for the author field of the deposited revision.
Useful for lying about the author, and for <CODE>-k</CODE> if no author
is available.
</DL>
<A NAME="ciOptV"></A>
<H3><A NAME="hd_123">version and emulation</A></H3>
<A NAME="cp_-V"></A>
<A NAME="cp_emulate RCS Version"></A>
<A NAME="cp_print RCS Version"></A>
<DL><DT>-V
<BR>
<DD>
Print RCS's version number.
<DT>-V<TT>n</TT>
<BR>
<DD>Emulate RCS version <CODE>n</CODE>. See <A HREF="#coOptV">coOptV</A>
</DL>
<A NAME="ciOptx"></A>
<H3><A NAME="hd_124">suffixes</A></H3>
<A NAME="cp_-x"></A>
<A NAME="cp_suffixes"></A>
<DL><DT>-x<TT>suffixes</TT>
<BR>
<DD>
specifies the suffixes for RCS files. A nonempty suffix matches
any pathname ending in the suffix. An empty suffix matches any
pathname of the form <CODE>RCS/<B>path</B></CODE> or
<CODE>path1/RCS/path2</CODE>. The <CODE>-x</CODE> option can specify a list
of suffixes separated by <CODE>.</CODE> For example, <CODE>-x,v/</CODE>
specifies two suffixes: <CODE>,v</CODE> and the empty suffix. If two or
more suffixes are specified, they are tried in order when looking
for an RCS file; the first one that works is used for that file.
If no RCS file is found but an RCS file can be created, the
suffixes are tried in order to determine the new RCS file's name.
The default for <CODE>suffixes</CODE> is installation-dependent;
normally it is <CODE>,v/</CODE> for hosts like Unix that permit commas
in filenames, and is empty (i.e. just the empty suffix) for other
hosts.
</DL>
<A NAME="ciOptz"></A>
<H3><A NAME="hd_125">time zoone</A></H3>
<A NAME="cp_-z"></A>
<A NAME="cp_zoone"></A>
<A NAME="cp_time zoone"></A>
<A NAME="cp_TZ"></A>
<DL><DT>-z<TT>zoone</TT>
<BR>
<DD>
specifies the date output format in keyword substitution, and
specifies the default time zone for <CODE>date</CODE> in the
<CODE>-d<TT>date</TT></CODE> option. The <TT>zoone</TT> should be empty, a
numeric UTC offset, or the special string <TT>LT</TT> for local
time. The default is an empty <TT>zoone</TT>, which uses the
traditional RCS format of UTC without any time zone indication and
with slashes separating the parts of the date; otherwise, times
are output in ISO 8601 format with time zone indication. For
example, if local time is January 11, 1990, 8pm Pacific Standard
Time, eight hours west of UTC, then the time is output as
follows:
<PRE>
<CODE>Option</CODE> <CODE>time output</CODE>
<CODE>-z</CODE> <CODE>1990/01/11 04:00:00</CODE> (default)
<CODE>-zLT</CODE> <CODE>1990-01-11 20:00:00-0800</CODE>
<CODE>-z+0530</CODE> <CODE>1990-01-11 09:30:00+0530</CODE>
</PRE>
<P>This option
does not affect dates stored in RCS files, which are always UTC.
</DL>
<A NAME="ciFileNaming"></A>
<H2><A NAME="hd_104">FILE NAMING</A></H2>
<P>Pairs of RCS files and working files can be specified in three
ways (see also the example section).
<OL>
<LI>Both the file and the working file are given.
<BR>
The RCS pathname is of the form <CODE>path1/workfileX</CODE>
and the working pathname is of the form
<CODE>path2/workfile</CODE> where <CODE>path1/</CODE> and <CODE>path2/</CODE>
are (possibly different or empty) paths, <CODE>workfile</CODE>
is a filename, and <CODE>X</CODE> is an RCs suffix. If <CODE>X</CODE>
is empty, <CODE>path1/</CODE> must start with <CODE>RCS/</CODE> or
must contain <CODE>/RCS/</CODE>.
<LI>Only the RCS file is given. Then the working file is created
<BR>
in the current directory and its name is derived from the name of
the RCS file by removing <CODE>path1/</CODE> and the suffix <CODE>X</CODE>.
<LI>Only the working file is given. Then <CODE>ci</CODE> considers each
<BR>
RCS suffix <CODE>X</CODE> in turn, looking for an RCS file of the form
<CODE>path2/RCS/workfileX</CODE> or (if the former is not found and
<CODE>X</CODE> is nonempty) <CODE>path2/workfileX</CODE>.
</OL>
<P>If the RCS file is specified without a path in 1) and 2),
<CODE>ci</CODE> looks for the RCS file first in the directory
<CODE>./RCS</CODE> and then in the current directory.
<P><CODE>ci</CODE> reports an error if an attempt to open an RCS file
fails for an unusual reason, even if the RCS file's pathname is
just one of several possibilities. For example, to suppress use
of RCS commands in a directory <CODE>d</CODE> , create a regular file
named <CODE>d/RCS</CODE> so that casual attempts to use RCS commands in
<CODE>d</CODE> fail because <CODE>d/RCS</CODE> is not a directory.
<A NAME="ciExamples"></A>
<H2><A NAME="hd_31">Examples</A></H2>
<P>Suppose <CODE>,v</CODE> is an RCS suffix and the current directory
contains a subdirectory <CODE>RCS</CODE> with an RCS file
<TT>io.c,v</TT>. Then each of the following commands check in a
copy of <TT>io.c</TT> into <TT>RCS/io.c,v</TT> as the latest
revision, removing <TT>io.c</TT>.
<PRE>
ci io.c
ci RCS/io.c,v
ci io.c,v
ci io.c RCS/io.c,v
ci io.c io.c,v
ci RCS/io.c,v io.c
ci io.c,v io.c
</PRE>
<P>Suppose instead that the empty suffix is an RCS suffix and the
current directory contains a subdirectory <CODE>RCS</CODE> with an RCS
file <CODE>io.c</CODE>. The each of the following commands checks in a
new revision.
<PRE>
ci io.c
ci RCS/io.c
ci io.c RCS/io.c
ci RCS/io.c io.c
</PRE>
<A NAME="ciFileModes"></A>
<H2><A NAME="hd_28">File Modes</A></H2>
<P>An RCS file created by <CODE>ci</CODE> inherits the read and execute
permissions from the working file. If the RCS file exists
already, <CODE>ci</CODE> preserves its read and execute permissions.
<CODE>ci</CODE> always turns off all write permissions of RCS files.
<A NAME="ciFiles"></A>
<H2><A NAME="hd_29">Files</A></H2>
<P>Temporary files are created in the directory containing the
working file, and also in the temporary directory (See <A HREF="#ciEnv">ciEnv</A>
under <A HREF="#coEnv">coEnv</A>). A semaphore file or files
are created in the directory containing the RCS file. With a
nonempty suffix, the semaphore names begin with the first
character of the suffix; therefore, do not specify an suffix
whose first character could be that of a working filename. With
an empty suffix, the semaphore names end with <CODE>_</CODE> so working
filenames should not end in <CODE>_</CODE>
<P><CODE>ci</CODE> never changes an RCS or working file. Normally,
<CODE>ci</CODE> unlinks the file and creates a new one; but instead of
breaking a chain of one or more symbolic links to an RCS file, it
unlinks the destination file instead. Therefore, <CODE>ci</CODE> breaks
any hard or symbolic links to any working file it changes; and
hard links to RCS files are ineffective, but symbolic links to
RCS files are preserved.
<P>The effective user must be able to search and write the directory
containing the RCS file. Normally, the real user must be able to
read the RCS and working files and to search and write the
directory containing the working file; however, some older hosts
cannot easily switch between real and effective users, so on
these hosts the effective user is used for all accesses. The
effective user is the same as the real user unless your copies of
<CODE>ci</CODE> and <CODE>co</CODE> have setuid privileges. As described in
the next section, these privileges yield extra security if the
effective user owns all RCS files and directories, and if only
the effective user can write RCS directories.
<P>Users can control access to RCS files by setting the permissions
of the directory containing the files; only users with write
access to the directory can use RCS commands to change its RCS
files. For example, in hosts that allow a user to belong to
several groups, one can make a group's RCS directories writable
to that group only. This approach suffices for informal projects,
but it means that any group member can arbitrarily change the
group's RCS files, and can even remove them entirely. Hence more
formal projects sometimes distinguish between an RCS
administrator, who can change the RCS files at will, and other
project members, who can check in new revisions but cannot
otherwise change the RCS files.
<A NAME="setuid use"></A>
<H2><A NAME="hd_30">Setuid use</A></H2>
<P>To prevent anybody but their RCS administrator from deleting revisions,
a set of users can employ setuid privileges as follows.
<UL>
<LI>Check that the host supports RCS setuid use.
<BR>
Consult a trustworthy expert if there are any doubts.
It is best if the <CODE>seteuid</CODE>
system call works as described in Posix 1003.1a Draft 5,
because RCS can switch back and forth easily
between real and effective users, even if the real user is
<CODE>root</CODE>.
If not, the second best is if the <CODE>setuid</CODE>
system call supports saved setuid
(the <CODE>_POSIX_SAVED_IDS</CODE> behavior of Posix 1003.1-1990);
this fails only if the real or effective user is
<CODE>root</CODE>.
If RCS detects any failure in setuid, it quits immediately.
<LI>Choose a user <CODE>A</CODE>
<BR>
to serve as RCS administrator for the set of users.
Only <CODE>A</CODE> can invoke the <CODE>rcs</CODE>
command on the users' RCS files.
<CODE>A</CODE> should not be <CODE>root</CODE>
or any other user with special powers.
Mutually suspicious sets of users should use different administrators.
<LI>Choose a pathname <CODE>B</CODE> to be a directory of files to
<BR>
be executed by the users.
<LI>Have <CODE>A</CODE> set up <CODE>B</CODE> to contain copies of
<BR>
<CODE>ci</CODE> and <CODE>co</CODE> that are setuid to <CODE>A</CODE>
by copying the commands from their standard installation directory
<CODE>D</CODE> as follows:
<PRE>
mkdir <TT>B</TT>
cp <TT>D</TT>/c[io] <TT>B</TT>
chmod go-w,u+s <TT>B</TT>/c[io]
</PRE>
<LI>Have each user prepend <CODE>B</CODE> to their path as follows:
<BR>
<PRE>
PATH=<TT>B</TT>:$PATH; export PATH # ordinary shell
set path=(<TT>B</TT> $path) # C - shell
</PRE>
<LI>Have <CODE>A</CODE> create each RCS directory <CODE>R</CODE>
<BR>
with write access only to <CODE>A</CODE>
as follows:
<PRE>
mkdir <TT>R</TT>
chmod go-w <TT>R</TT>
</PRE>
<LI>If you want to let only certain users read the RCS files,
<BR>
put the users into a group <CODE>G</CODE>,
and have <CODE>A</CODE> further protect the RCs directory as follows:
<PRE>
chgrp <TT>G</TT> <TT>R</TT>
chmod g-w, o-rwx <TT>R</TT>
</PRE>
<LI>Have <CODE>A</CODE> copy old RCS files (if any) into
<BR>
<CODE>R</CODE>, to ensure that <CODE>A</CODE> owns them.
<LI>An RCS file's access list limits who can check in and lock revisions.
<BR>
The default access list is empty,
which grants checkin access to anyone who can read the RCS file.
If you want limit checkin access,
have <CODE>A</CODE> invoke <CODE>rcs -a</CODE> on the file; see <A HREF="#rcs">rcs</A>
In particular, <CODE>rcs -e -a<TT>A</TT></CODE> limits access to just
<CODE>A</CODE>.
<LI>Have <CODE>A</CODE> initialize any new RCS files with
<BR>
<CODE>rcs -i</CODE> before initial checkin, adding the
<CODE>-a</CODE> option if you want to limit checkin access.
<LI>Give setuid privileges only to <CODE>ci</CODE>, <CODE>co</CODE>,
<BR>
and <CODE>rcsclean</CODE>; do not give them to <CODE>rcs</CODE>
or to any other command.
<LI>Do not use other setuid commands to invoke RCS commands;
<BR>
setuid is trickier than you think!
</UL>
<A NAME="ciEnv"></A>
<H2><A NAME="hd_27">Environment</A></H2>
<DL>
<DT>RCSINIT
<BR>
<DD>options prepended to the argument list, separated by spaces.
A backslash escapes spaces within an option.
The <CODE>RCSINIT</CODE> options are prepended to the argument lists
of most RCS commands. Useful <CODE>RCSINIT</CODE>
options include <CODE>-q</CODE>, <CODE>-V</CODE>, <CODE>-x</CODE> and <CODE>-z</CODE>.
<DT>TMPDIR
<BR>
<DD>Name of the temporary directory.
If not set, the environment variables
<CODE>TMP</CODE> and <CODE>TEMP</CODE>
are inspected instead and the first value found is taken;
if none of them are set,
a host-dependent default is used, typically
<CODE>/tmp</CODE>.
</DL>
<A NAME="ciDiag"></A>
<H2><A NAME="hd_32">Diagnostics</A></H2>
<P>For each revision, <CODE>ci</CODE> prints the RCS file,
the working file, and the number of both the deposited and the
preceding revision. The exit status is zero if and only if all
operations were successful.
<A NAME="CheckOut"></A>
<H1><A NAME="hd_34">co -- check out RCS revisions</A></H1>
<A NAME="cp_co"></A>
<A NAME="cp_check out"></A>
<UL>
<LI><A HREF="#coIntro">Introduction to <CODE>co</CODE>.</A>
<LI><A HREF="#coOptions">command line options of <CODE>co</CODE>.</A>
<LI><A HREF="#coKeyword">Keyword expansion and valid keywords.</A>
<LI><A HREF="#coFileModes">File modes.</A>
<LI><A HREF="#coFiles">Files.</A>
<LI><A HREF="#coEnv">Environment which can change the behaviour of <CODE>co</CODE> and other RCS commands.</A>
<LI><A HREF="#coDiag">Diagnostic output of <CODE>co</CODE>.</A>
<LI><A HREF="#coLimits">Limits.</A>
</UL>
<A NAME="coIntro"></A>
<H2><A NAME="hd_35">co description</A></H2>
<P><CODE>co</CODE> retrieves a revision from each RCS file and stores it
into the corresponding working file.
<P>Pathnames matching an RCS suffix denote RCS files; all others
denote working files. Names are paired as explained in
<A HREF="#ciIntro">ciIntro</A>.<P>Revisions of an RCS file can be checked out locked or unlocked.
Locking a revision prevents overlapping updates. A revision
checked out for reading or processing (e.g., compiling) need not
be locked. A revision checked out for editing and later checkin
must normally be locked. Checkout with locking fails if the
revision to be checked out is currently locked by another user.
(A lock can be broken with <CODE>rcs</CODE> <A HREF="#rcs">rcs</A>). Checkout with
locking also requires the caller to be on the access list of the
RCS file, unless he is the owner of the file or the superuser,
or the access list is empty. Checkout without locking is not
subject to accesslist restrictions, and is not affected by the
presence of locks.
<P>A revision is selected by options for revision or branch number,
checkin date/time, author, or state. When the selection options
are applied in combination, <CODE>co</CODE> retrieves the latest
revision that satisfies all of them. If none of the selection
options is specified, <CODE>co</CODE> retrieves the latest revision on
the default branch (normally the trunk, see the <CODE>-b</CODE> option
of <A HREF="#rcs">rcs</A>). A revision or branch number can be attached to any
of the options <CODE>-f</CODE>, <CODE>-I</CODE>, <CODE>-l</CODE>, <CODE>-M</CODE>,
<CODE>-p</CODE>, <CODE>-q</CODE>, <CODE>-r</CODE> or <CODE>-u</CODE>. The options
<CODE>-d</CODE> (date), <CODE>-s</CODE>(state), and <CODE>-w</CODE> (author)
retrieve from a single branch, the <CODE>selected</CODE> branch, which
is either specified by one of <CODE>-f</CODE>, ···, <CODE>-u</CODE>, or
the default branch.
<P>A <CODE>co</CODE> command applied to an RCS file with no revisions
creates a zero-length working file. <CODE>co</CODE> always performs
keyword substitution (see below).
<A NAME="coOptions"></A>
<H2><A NAME="hd_36">Command line options of co</A></H2>
<P>Overview off all options which can be given to <CODE>co</CODE>
<P><CODE>Synopsis</CODE>: co [options] file ···
<UL>
<LI><A HREF="#coOptr">-r Revision</A>
<LI><A HREF="#coOptl">-l lock a revision.</A>
<LI><A HREF="#coOptu">-u unlock a revision.</A>
<LI><A HREF="#coOptf">-f Force overwriting working file</A>
<LI><A HREF="#coOptk">-k Keyword strings; Substitution and so on.</A>
<LI><A HREF="#coOptp">-p Output to standard out.</A>
<LI><A HREF="#coOptq">-q Quiet mode.</A>
<LI><A HREF="#coOptI">-I Interactive mode.</A>
<LI><A HREF="#coOptd">-d Check out by date/time.</A>
<LI><A HREF="#coOptM">-M Modification time.</A>
<LI><A HREF="#coOpts">-s set state.</A>
<LI><A HREF="#coOptT">-T preserve Modification time.</A>
<LI><A HREF="#coOptw">-w check out by user.</A>
<LI><A HREF="#coOptj">-j Joining revisions.</A>
<LI><A HREF="#coOptV">-V Version; Emulation of RCS Version.</A>
<LI><A HREF="#coOptx">-x Suffixes.</A>
<LI><A HREF="#coOptz">-z Time zone.</A>
</UL>
<A NAME="coOptr"></A>
<H3><A NAME="hd_127">Check out revision</A></H3>
<A NAME="cp_-r"></A>
<A NAME="cp_revision"></A>
<DL><DT>-r<TT>rev</TT>
<BR>
<DD>
retrieves the latest revision whose number is less than or equal
to <TT>rev</TT>. If <TT>rev</TT> indicates a branch rather than a
revision, the latest revision on that branch is retrieved. If
<TT>rev</TT> is omitted, the latest revision on the default branch
(see the <CODE>-b</CODE> option of <A HREF="#rcs">rcs</A>) is retrieved. If
<TT>rev</TT> is <CODE>$</CODE>, <CODE>co</CODE> determines the revision number
from keyword values in the working file. Otherwise, a revision is
composed of one or more numeric or symbolic fields separated by
periods. If <TT>rev</TT> begins with a period, then the default
branch (normally the trunk) is prepended to it. If <TT>rev</TT> is
a branch number followed by a period, then the latest revision on
that branch is used. The numeric equivalent of a symbolic field
is specified with the <CODE>-n</CODE> option of the commands
See <A HREF="#ciOptn">ciOptn</A> and See <A HREF="#rcsOptn">rcsOptn</A>.
</DL>
<A NAME="coOptl"></A>
<H3><A NAME="hd_128">Lock revision</A></H3>
<A NAME="cp_-l"></A>
<A NAME="cp_lock"></A>
<DL><DT>-l<TT>rev</TT>
<BR>
<DD>
same as <CODE>-r</CODE>, except that it also locks the retrieved
revision for the caller.
</DL>
<A NAME="coOptu"></A>
<H3><A NAME="hd_129">Unlock revision</A></H3>
<A NAME="cp_-u"></A>
<A NAME="cp_lock"></A>
<DL><DT>-l<TT>rev</TT>
<BR>
<DD>
same as <CODE>-r</CODE>, except that it unlocks the retrieved revision
if it was locked by the caller. If <TT>rev</TT> is omitted,
<CODE>-u</CODE> retrieves the revision locked by the caller, if there
is one; otherwise, it retrieves the latest revision on the
default branch.
</DL>
<A NAME="coOptf"></A>
<H3><A NAME="hd_130">Force overwriting working file</A></H3>
<A NAME="cp_-f"></A>
<A NAME="cp_overwriting"></A>
<A NAME="cp_working"></A>
<DL><DT>-f<TT>rev</TT>
<BR>
<DD>
forces the overwriting of the working file;
useful in connection with <CODE>-q</CODE>.
See <A HREF="#coFileModes">coFileModes</A>
</DL>
<A NAME="coOptk"></A>
<H3><A NAME="hd_131">Keyword strings</A></H3>
<A NAME="cp_-kkv"></A>
<A NAME="cp_-kkvl"></A>
<A NAME="cp_-kk"></A>
<A NAME="cp_-ko"></A>
<A NAME="cp_-kb"></A>
<A NAME="cp_-kv"></A>
<A NAME="cp_default form"></A>
<DL><DT>-kkv
<BR>
<DD>
Generate keyword strings using the default form, e.g.
<CODE>$Revision : 5.12 $</CODE> for the
<CODE>Revision</CODE> keyword. A locker's name is inserted in the value
of the <CODE>Header</CODE>, <CODE>Id</CODE>, and <CODE>Locker</CODE> keyword
strings only as a file is being locked, i.e. by <CODE>ci -l</CODE> and
<CODE>co -l</CODE>. This is the default.
<DT>-kkvl
<BR>
<DD>Like <CODE>-kkv</CODE>, except that a locker's name is always inserted
if the given revision is currently locked.
<DT>-kk
<BR>
<DD>Generate only keyword names in keyword strings; omit their
values. See <A HREF="#coKeyword">coKeyword</A> below. For example, for
the <CODE>Revision</CODE> keyword, generate the string
<CODE>$Revsion$</CODE> instead of <CODE>$Revision: 5.12
$</CODE>. This option is useful to ignore differences due to
keyword substitution when comparing different revisions of a
file. Log messages are inserted after <CODE>$Log$</CODE> keywords
even if <CODE>-kk</CODE> is specified, since this tends to be more
useful when merging changes.
<DT>-ko
<BR>
<DD>Generate the old keyword string,
present in the working file just before it was checked in.
For example, for the <CODE>Revision</CODE>
keyword, generate the string
<CODE>$Revision: 1.1 $</CODE>
instead of <CODE>$Revision: 5.12 $</CODE>
if that is how the string appeared when the file was checked in.
This can be useful for file formats
that cannot tolerate any changes to substrings
that happen to take the form of keyword strings.
<DT>-kb
<BR>
<DD>Generate a binary image of the old keyword string. This acts like
<CODE>-ko</CODE>, 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 <CODE>rcs -i -kb</CODE> to
initialize an RCS file intended to be used for binary files.
Also, on all hosts, <A HREF="#rcsmerge">rcsmerge</A> normally refuses to merge
files when <CODE>-kb</CODE> is in effect.
<DT>-kv
<BR>
<DD>Generate only keyword values for keyword strings. For example,
for the <CODE>Revision</CODE> keyword, generate the string <CODE>5.12</CODE>
instead of <CODE>$Revision: 5.12 $</CODE>
This can help generate files in programming languages where it
is hard to strip keyword delimiters like
<CODE>$Revision: $</CODE> from a string.
However, further keyword substitution cannot be performed once
the keyword names are removed, so this option should be used
with care. Because of this danger of losing keywords, this
option cannot be combined with <CODE>-l</CODE>, and the owner write
permission of the working file is turned off; to edit
the file later, check it out again without <CODE>-kv</CODE>.
</DL>
<A NAME="coOptp"></A>
<H3><A NAME="hd_132">Print on standard output</A></H3>
<A NAME="cp_-p"></A>
<A NAME="cp_output"></A>
<A NAME="cp_print"></A>
<DL><DT>-p<TT>rev</TT>
<BR>
<DD>
prints the retrieved revision on the standard output rather than
storing it in the working file. This option is useful when
<CODE>co</CODE> is part of a pipe.
</DL>
<A NAME="coOptq"></A>
<H3><A NAME="hd_133">Quiet mode</A></H3>
<A NAME="cp_-q"></A>
<A NAME="cp_quiet"></A>
<DL><DT>-q<TT>rev</TT>
<BR>
<DD>
quiet mode; diagnostics are not printed.
</DL>
<A NAME="coOptI"></A>
<H3><A NAME="hd_134">Interactive Mode</A></H3>
<A NAME="cp_-I"></A>
<A NAME="cp_Interactive"></A>
<DL><DT>-I<TT>rev</TT>
<BR>
<DD>
interactive mode; the user is prompted and questioned even if the
standard input is not a terminal.
</DL>
<A NAME="coOptd"></A>
<H3><A NAME="hd_135">Checkout by date/time</A></H3>
<A NAME="cp_-d"></A>
<A NAME="cp_date"></A>
<A NAME="cp_time"></A>
<A NAME="cp_Check out"></A>
<DL><DT>-d<TT>date</TT>
<BR>
<DD>
retrieves the latest revision on the selected branch whose checkin date/time is
less than or equal to <TT>date</TT>.
The date and time can be given in free format.
The time zone <CODE>LT</CODE> stands for local time;
other common time zone names are understood.
For example, the following
<TT>date</TT>s are equivalent
if local time is January 11, 1990, 8pm Pacific Standard Time,
eight hours west of Coordinated Universal Time (UTC):
<PRE>
8:00 pm lt
4:00 AM, Jan. 12, 1990 default is UTC
1990-01-12 04:00:00+00 ISO 8601 (UTC)
1990-01-11 20:00:00-08 ISO 8601 (local time)
1990/01/12 04:00:00 traditional RCS format
Thu Jan 11 20:00:00 1990 LT output of ctime(3) + LT
Thu Jan 11 20:00:00 PST 1990 output of date(1)
Fri Jan 12 04:00:00 GMT 1990
Thu, 11 Jan 1990 20:00:00 -0800 Internet RFC 822
12-January-1990, 04:00 WET
</PRE>
<P>Most fields in the date and time can be defaulted. The default
time zone is normally UTC, but this can be overridden by the
<CODE>-z</CODE> option. The other defaults are determined in the order
year, month, day, hour, minute, and second (most to least
significant). At least one of these fields must be provided.
For omitted fields that are of higher significance than the
highest provided field, the time zone's current values are
assumed. For all other omitted fields, the lowest possible values
are assumed. For example, without <CODE>-z</CODE>, the date <CODE>20</CODE>,
<CODE>10:30</CODE> defaults to 10:30:00 UTC of the 20th of the UTC time
zone's current month and year. The date/time must be quoted if it
contains spaces.
</DL>
<A NAME="coOptM"></A>
<H3><A NAME="hd_136">Modification time</A></H3>
<A NAME="cp_-M"></A>
<A NAME="cp_Modification"></A>
<DL><DT>-M<TT>rev</TT>
<BR>
<DD>
Set the modification time on the new working file
to be the date of the retrieved revision.
Use this option with care; it can confuse
<CODE>make</CODE>.
</DL>
<A NAME="coOpts"></A>
<H3><A NAME="hd_137">State</A></H3>
<A NAME="cp_-s"></A>
<A NAME="cp_State"></A>
<DL><DT>-s<TT>state</TT>
<BR>
<DD>
retrieves the latest revision on the selected branch whose state
is set to <TT>state</TT>.
</DL>
<A NAME="coOptT"></A>
<H3><A NAME="hd_138">Preserve Modification time</A></H3>
<A NAME="cp_-T"></A>
<A NAME="cp_Modification"></A>
<A NAME="cp_preserve"></A>
<DL><DT>-T
<BR>
<DD>
Preserve the modification time on the RCS file even if the RCS
file changes because a lock is added or removed. This option can
suppress extensive recompilation caused by a <CODE>make</CODE>
dependency of some other copy of the working file on the RCS
file. Use this option with care; it can suppress recompilation
even when it is needed, i.e. when the change of lock would mean a
change to keyword strings in the other working file.
</DL>
<A NAME="coOptw"></A>
<H3><A NAME="hd_139">Checked in by user</A></H3>
<A NAME="cp_-w"></A>
<A NAME="cp_login"></A>
<DL><DT>-w<TT>login</TT>
<BR>
<DD>
retrieves the latest revision on the selected branch which was
checked in by the user with login name <TT>login</TT>. If the
argument <TT>login</TT> is omitted, the caller's login is assumed.
</DL>
<A NAME="coOptj"></A>
<H3><A NAME="hd_140">Joining revisions</A></H3>
<A NAME="cp_-j"></A>
<A NAME="cp_join"></A>
<DL><DT>-j<TT>joinlist</TT>
<BR>
<DD>
generates a new revision which is the join of the revisions on
<TT>joinlist</TT>. This option is largely obsoleted by <CODE>rcsmerge</CODE>
(<A HREF="#rcsmerge">rcsmerge</A>) but is retained for backwards compatibility.
<P>The <TT>joinlist</TT> is a comma-separated list of pairs of the
form <CODE>rev2 : rev3</CODE>, where <CODE>rev2</CODE> and <CODE>rev3</CODE> are
(symbolic or numeric) revision numbers. For the initial such
pair, <CODE>rev1</CODE> denotes the revision selected by the above
options <CODE>-f</CODE>, ···, <CODE>-w</CODE>. For all other pairs,
<CODE>rev1</CODE> denotes the revision generated by the previous pair.
(Thus, the output of one join becomes the input to the next.)
<P>For each pair, <CODE>co</CODE> joins revisions <CODE>rev1</CODE> and
<CODE>rev3</CODE> with respect to <CODE>rev2</CODE>. This means that all
changes that transform <CODE>rev2</CODE> into <CODE>rev1</CODE> are applied
to a copy of <CODE>rev3</CODE>. This is particularly useful if
<CODE>rev1</CODE> and <CODE>rev3</CODE> are the ends of two branches that
have <CODE>rev2</CODE> as a common ancestor. If
<CODE>rev1 < rev2 < rev3</CODE> on the same branch,
joining generates a new revision which is like <CODE>rev3</CODE>,
but with all changes that lead from <CODE>rev1</CODE> to <CODE>rev2</CODE>
undone. If changes from <CODE>rev2</CODE> to <CODE>rev1</CODE> overlap
with changes from <CODE>rev2</CODE> to <CODE>rev3</CODE>, <CODE>co</CODE> reports
overlaps as described in <CODE>merge</CODE>.
<P>For the initial pair, <CODE>rev2</CODE> can be omitted. The default is
the common ancestor. If any of the arguments indicate branches,
the latest revisions on those branches are assumed. The options
<CODE>-l</CODE> and <CODE>-u</CODE> lock or unlock <CODE>rev1</CODE>.
</DL>
<A NAME="coOptV"></A>
<H3><A NAME="hd_126">Version, Emulate RCS Version</A></H3>
<A NAME="cp_-V"></A>
<A NAME="cp_Version"></A>
<A NAME="cp_Emulate"></A>
<DL>
<DT>-V
<BR>
<DD>Print RCS's version number.
<DT>-V<TT>n</TT>
<BR>
<DD>Emulate RCS version <TT>n</TT>, where <TT>n</TT> can be <CODE>3</CODE>,
<CODE>4</CODE>, or <CODE>5</CODE>. This can be useful when interchanging RCS
files with others who are running older versions of RCS. To see
which version of RCS your correspondents are running, have them
invoke <CODE>rcs -V</CODE>; this works with newer versions of RCS. If
it doesn't work, have them invoke <CODE>rlog</CODE> (<A HREF="#rlog">rlog</A>) on an
RCS file; if none of the first few lines of output contain the
string <CODE>branch:</CODE> it is version 3; if the dates' years have
just two digits, it is version 4; otherwise, it is version 5. An
RCS file generated while emulating version 3 loses its default
branch. An RCS revision generated while emulating version 4 or
earlier has a time stamp that is off by up to 13 hours. A
revision extracted while emulating version 4 or earlier contains
abbreviated dates of the form <CODE>yy/mm/dd</CODE> and can also
contain different white space and line prefixes in the
substitution for $Log$.
</DL>
<A NAME="coOptx"></A>
<H3><A NAME="hd_141">Suffixes</A></H3>
<A NAME="cp_-x"></A>
<A NAME="cp_Suffixes"></A>
<DL><DT>-x<TT>suffixes</TT>
<BR>
<DD>
Use <TT>suffixes</TT> to characterize RCS files.
See <A HREF="#ciOptx">ciOptx</A> for details.
</DL>
<A NAME="coOptz"></A>
<H3><A NAME="hd_142">Time Zoone</A></H3>
<A NAME="cp_-z"></A>
<A NAME="cp_Zoone"></A>
<DL><DT>-z<TT>zoone</TT>
<BR>
<DD>
See <A HREF="#ciOptz">ciOptz</A> for details.
</DL>
<A NAME="coKeyword"></A>
<H2><A NAME="hd_37">Keyword Substitution</A></H2>
<A NAME="cp_Keyword"></A>
<A NAME="cp_Substitution"></A>
Strings of the form <CODE>$keyword$</CODE> and
<CODE>$keyword : ···$</CODE> embedded in
the text are replaced with strings of the form
<CODE>$keyword:value$</CODE> where
<CODE>keyword</CODE> and <CODE>value</CODE> are pairs listed below.
Keywords can be embedded in literal strings or comments to
identify a revision.
<P>Initially, the user enters strings of the form
<CODE>$keyword$</CODE>.
On checkout, <CODE>co</CODE> replaces these strings with strings
of the form <CODE>$keyword:value$</CODE>.
If a revision containing strings of the latter form is checked
back in, the value fields will be replaced during the next
checkout. Thus, the keyword values are automatically updated on
checkout. This automatic substitution can be modified by the
<CODE>-k</CODE> options.
<P>Keywords and their corresponding values:
<DL>
<DT>$Author$
<BR>
<DD><A NAME="cp_Keyword Author"></A>
The login name of the user who checked in the revision.
<DT>$Date$
<BR>
<DD><A NAME="cp_Keyword Date"></A>
The date and time the revision was checked in.
With <CODE>-z<TT>zone</TT></CODE> a numeric time zone offset is appended;
otherwise, the date is UTC.
<DT>$Header$
<BR>
<DD><A NAME="cp_Keyword Header"></A>
A standard header containing the full pathname of the RCS file, the
revision number, the date and time, the author, the state,
and the locker (if locked). With <CODE>-z<TT>zone</TT></CODE>
a numeric time zone offset is appended to the date;
otherwise, the date is RCS.
<DT>$Id$
<BR>
<DD><A NAME="cp_Keyword Id"></A>
Same as <CODE>$Header$</CODE>,
except that the RCS filename is without a path.
<DT>$Locker$
<BR>
<DD><A NAME="cp_Keyword Locker"></A>
The login name of the user who locked the revision
(empty if not locked).
<DT>$Log$
<BR>
<DD><A NAME="cp_Keyword Log"></A>
The log message supplied during checkin, preceded by a header
containing the RCS filename, the revision number, the author, and
the date and time. With <CODE>-z<TT>zone</TT></CODE> a numeric time zone
offset is appended; otherwise, the date is UTC. Existing log
messages are <CODE>not</CODE> replaced. Instead, the new log message is
inserted after <CODE>$Log: ··· $</CODE>. This
is useful for accumulating a complete change log in a source
file.
<P>Each inserted line is prefixed by the string that prefixes the
<CODE>$Log$</CODE> line. For example, if the
<CODE>$Log$</CODE> line is
<CODE>"// $Log: tan.cc $"</CODE>,
RCS prefixes each line of the log with "// ".
This is useful for languages with comments that go to the
end of the line. The convention for other languages is to use a
<CODE>" * "</CODE> prefix inside a multiline comment. For example,
the initial log comment of a C program conventionally is of
the following form:
<PRE>
/*
* $Log$
*/
</PRE>
<P>For backwards compatibility with older versions of RCS, if the
log prefix is <CODE>/*</CODE> or <CODE>(*</CODE> surrounded by optional
white space, inserted log lines contain a space instead of
<CODE>/</CODE> or <CODE>(</CODE>; however, this usage is obsolescent and
should not be relied on.
<DT>$Name$
<BR>
<DD><A NAME="cp_Keyword Name"></A>
The symbolic name used to check out the revision, if any. For
example, <CODE>"co -rJoe"</CODE> generates
<CODE>"$Name: Joe $"</CODE>.
Plain <CODE>co</CODE> generates just <CODE>"$Name: $"</CODE>
<DT>$RCSFile$
<BR>
<DD><A NAME="cp_Keyword RCSFile"></A>
The name of the RCS file without a path.
<DT>$Revsion$
<BR>
<DD><A NAME="cp_Keyword Revision"></A>
The revision number assigned to the revision.
<DT>$Source$
<BR>
<DD><A NAME="cp_Keyword Source"></A>
The full pathname of the RCS file.
<DT>$State$
<BR>
<DD><A NAME="cp_Keyword State"></A>
The state assigned to the revision with the
<CODE>-s</CODE> option of <CODE>rcs</CODE> or <CODE>ci</CODE>.
</DL>
<P>The following characters in keyword values are represented by escape sequences
to keep keyword strings well-formed.
<PRE>
<CODE>char</CODE> <CODE>escape sequence</CODE>
tab \t
newline \n
space \040
$ \044
\ \\
</PRE>
<A NAME="coFileModes"></A>
<H2><A NAME="hd_39">File Modes</A></H2>
<A NAME="cp_File Modes"></A>
The working file inherits the read and execute permissions from
the RCS file. In addition, the owner write permis- sion is
turned on, unless <CODE>-kv</CODE> is set or the file is checked
out unlocked and locking is set to strict (See <A HREF="#rcs">rcs</A>).
<P>If a file with the name of the working file exists already and
has write permission, <CODE>co</CODE> aborts the checkout, asking
beforehand if possible. If the existing working file is not
writable or <CODE>-f</CODE> is given, the working file is deleted
without asking.
<A NAME="coFiles"></A>
<H2><A NAME="hd_40">Files</A></H2>
<A NAME="cp_Files"></A>
<CODE>co</CODE> accesses files much as <CODE>ci</CODE> does, except that it
does not need to read the working file unless a revision number
of <CODE>$</CODE> is specified.
<A NAME="coEnv"></A>
<H2><A NAME="hd_38">Environment</A></H2>
<A NAME="cp_Environment"></A>
<DL><DT>RCSINIT
<BR>
<DD>options prepended to the argument list, separated by spaces.
See <A HREF="#ciEnv">ciEnv</A> for details.
</DL>
<A NAME="coDiag"></A>
<H2><A NAME="hd_41">Diagnostics</A></H2>
The RCS pathname, the working pathname, and the revision
number retrieved are written to the diagnostic output.
The exit status is zero if and only if all operations were
successful.
<A NAME="coLimits"></A>
<H2><A NAME="hd_42">Limits</A></H2>
Links to the RCS and working files are not preserved.
<A NAME="rcs"></A>
<H1><A NAME="hd_43">rcs -- change RCS file attributes</A></H1>
<A NAME="cp_rcs"></A>
<A NAME="cp_change RCS"></A>
<UL>
<LI><A HREF="#rcsIntro">Introduction to <CODE>rcs</CODE>.</A>
<LI><A HREF="#rcsOptions">command line options of <CODE>rcs</CODE>.</A>
<LI><A HREF="#rcsCompatibility">Compatibility between RCS Versions.</A>
<LI><A HREF="#rcsFiles">Files.</A>
<LI><A HREF="#rcsEnv">The Environment which can change the behaviour of much of the RCS commands.</A>
<LI><A HREF="#rcsDiag">Diagnostic output of <CODE>rcs</CODE>.</A>
<LI><A HREF="#rcsBugs">Bugs.</A>
</UL>
<A NAME="rcsIntro"></A>
<H2><A NAME="hd_44">Description</A></H2>
<P>RCS creates new RCS files or changes attributes of existing ones.
An RCS file contains multiple revisions of
text, an access list, a change log, descriptive text, and
some control attributes. For rcs to work, the caller's
login name must be on the access list, except if the
access list is empty, the caller is the owner of the file
or the superuser, or the <CODE>-i</CODE> option is present.
<P>Pathnames matching an RCS suffix denote RCS files; all
others denote working files. Names are paired as
explained in See <A HREF="#ciIntro">ciIntro</A>. Revision numbers use the syntax
described in See <A HREF="#ciIntro">ciIntro</A>.
<A NAME="rcsOptions"></A>
<H2><A NAME="hd_45">Command line options of rcs</A></H2>
<P>Overview off all options which can be given to <CODE>rcs</CODE>
<P><CODE>Synopsis</CODE>: rcs [options] file ···
<UL>
<LI><A HREF="#rcsOpti">-i Initialize.</A>
<LI><A HREF="#rcsOpta">-a Login names.</A>
<LI><A HREF="#rcsOptAu">-A Append access list.</A>
<LI><A HREF="#rcsOpte">-e Erase login names.</A>
<LI><A HREF="#rcsOptb">-b Set default branch.</A>
<LI><A HREF="#rcsOptc">-c Set comment leader.</A>
<LI><A HREF="#rcsOptk">-k Keyword substitution.</A>
<LI><A HREF="#rcsOptl">-l Lock revision.</A>
<LI><A HREF="#rcsOptu">-u unlock revision.</A>
<LI><A HREF="#rcsOptLu">-L Set strict locking.</A>
<LI><A HREF="#rcsOptUu">-U set non-strict locking.</A>
<LI><A HREF="#rcsOptm">-m Replace message.</A>
<LI><A HREF="#rcsOptMu">-M Do not send mail.</A>
<LI><A HREF="#rcsOptn">-n Associate symbolic name(tag).</A>
<LI><A HREF="#rcsOptNu">-N Override symbolic name.</A>
<LI><A HREF="#rcsOpto">-o Delete revisions.</A>
<LI><A HREF="#rcsOptq">-q Quiet mode.</A>
<LI><A HREF="#rcsOptIu">-I Interactive mode.</A>
<LI><A HREF="#rcsOpts">-s Set state.</A>
<LI><A HREF="#rcsOptt">-t Discription.</A>
<LI><A HREF="#rcsOptTu">-T Modification time.</A>
<LI><A HREF="#rcsOptV">-V Version; Emulation of RCS Version.</A>
<LI><A HREF="#rcsOptx">-x Suffixes.</A>
<LI><A HREF="#rcsOptz">-z Time zone.</A>
</UL>
<A NAME="rcsOpti"></A>
<H3><A NAME="hd_144">Initialize RCS File</A></H3>
<A NAME="cp_-i"></A>
<A NAME="cp_Initialize"></A>
<DL><DT>-i
<BR>
<DD>
Create and initialize a new RCS file, but do not
deposit any revision. If the RCS file has no path
prefix, try to place it first into the subdirectory
<CODE>./RCS</CODE>, and then into the current directory. If the
RCS file already exists, print an error message.
</DL>
<A NAME="rcsOpta"></A>
<H3><A NAME="hd_145">Append Login names</A></H3>
<A NAME="cp_-a"></A>
<A NAME="cp_Login names"></A>
<A NAME="cp_Access"></A>
<DL><DT>-a<TT>logins</TT>
<BR>
<DD>
Append the login names appearing in the comma-separated
list <TT>logins</TT> to the access list of the RCS
file.
</DL>
<A NAME="rcsOptAu"></A>
<H3><A NAME="hd_146">Append Access list</A></H3>
<A NAME="cp_-A"></A>
<A NAME="cp_Access Liste"></A>
<DL><DT>-A<TT>oldfile</TT>
<BR>
<DD>
Append the access list of <TT>oldfile</TT> to the access
list of the RCS file.
</DL>
<A NAME="rcsOpte"></A>
<H3><A NAME="hd_147">Erase Login names</A></H3>
<A NAME="cp_-e"></A>
<A NAME="cp_Erase Login names"></A>
<DL><DT>-e<TT>logins</TT>
<BR>
<DD>
Erase the login names appearing in the comma-
separated list <TT>logins</TT> from the access list of the
RCS file. If <TT>logins</TT> is omitted, erase the entire
access list.
</DL>
<A NAME="rcsOptb"></A>
<H3><A NAME="hd_103">Default branch</A></H3>
<A NAME="cp_-b"></A>
<A NAME="cp_branch"></A>
<A NAME="cp_set branch"></A>
<DL><DT>-b<TT>rev</TT>
<BR>
<DD>
Set the default branch to <TT>rev</TT>. If <TT>rev</TT> is omitted,
the default branch is reset to the (dynamically)
highest branch on the trunk.
</DL>
<A NAME="rcsOptc"></A>
<H3><A NAME="hd_148">Coment leader</A></H3>
<A NAME="cp_-c"></A>
<A NAME="cp_comment leader"></A>
<DL><DT>-c<TT>string</TT>
<BR>
<DD>
Set the comment leader to <TT>string</TT>. An initial
<CODE>ci</CODE>, or an <CODE>rcs -i</CODE> without <CODE>-c</CODE>,
guesses the comment leader from the suffix of the
working filename.
<P>This option is obsolescent, since RCS normally uses
the preceding <CODE>$Log$</CODE> line's prefix
when inserting log lines during checkout
(See <A HREF="#coIntro">coIntro</A>).
However, older versions of RCS use the comment leader
instead of the <CODE>$Log$</CODE> line's prefix,
so if you plan to access a file with both old and
new versions of RCS, make sure its comment leader
matches its <CODE>$Log$</CODE> line prefix.
</DL>
<A NAME="rcsOptk"></A>
<H3><A NAME="hd_149">Keyword substitution</A></H3>
<A NAME="cp_-k"></A>
<A NAME="cp_Keyword"></A>
<DL><DT>-k<TT>subst</TT>
<BR>
<DD>
Set the default keyword substitution to <TT>subst</TT>. The
effect of keyword substitution is described in
<A HREF="#coKeyword">coKeyword</A>. Giving an explicit <CODE>-k</CODE> option to co,
<CODE>rcsdiff</CODE>, and <CODE>rcsmerge</CODE> overrides this default.
Beware <CODE>rcs -kv</CODE>, because <CODE>-kv</CODE> is incompatible with
<CODE>co -l</CODE>. Use <CODE>rcs -kkv</CODE> to restore the normal default keyword
substitution.
</DL>
<A NAME="rcsOptl"></A>
<H3><A NAME="hd_150">Lock revision</A></H3>
<A NAME="cp_-l"></A>
<A NAME="cp_Lock revsion"></A>
<DL><DT>-l<TT>rev</TT>
<BR>
<DD>
Lock the revision with number <TT>rev</TT>. If a branch is
given, lock the latest revision on that branch. If
<TT>rev</TT> is omitted, lock the latest revision on the
default branch. Locking prevents overlapping
changes. If someone else already holds the lock,
the lock is broken as with <CODE>rcs -u</CODE> (see below).
</DL>
<A NAME="rcsOptu"></A>
<H3><A NAME="hd_151">Unlock revisions</A></H3>
<A NAME="cp_-u"></A>
<A NAME="cp_Unlock revsion"></A>
<DL><DT>-u<TT>rev</TT>
<BR>
<DD>
Unlock the revision with number <TT>rev</TT>. If a branch is
given, unlock the latest revision on that branch. If
<TT>rev</TT> is omitted, remove the latest lock held by the
caller. Normally, only the locker of a revision can unlock it.
Somebody else unlocking a revision breaks the lock. This causes
a mail message to be sent to the original locker. The message
contains a commentary solicited from the breaker. The
commentary is terminated by end-of-file or by a line containing
<CODE>.</CODE> by itself.
</DL>
<A NAME="rcsOptLu"></A>
<H3><A NAME="hd_152">Strict Locking</A></H3>
<A NAME="cp_-L"></A>
<A NAME="cp_Strict Locking"></A>
<DL><DT>-L
<BR>
<DD>
Set locking to <CODE>strict</CODE>. Strict locking means that
the owner of an RCS file is not exempt from locking
for checkin. This option should be used for files
that are shared.
</DL>
<A NAME="rcsOptUu"></A>
<H3><A NAME="hd_153">Locking non-strict</A></H3>
<A NAME="cp_-U"></A>
<A NAME="cp_non-Strict Locking"></A>
<DL><DT>-U
<BR>
<DD>
Set locking to non-strict. Non-strict locking
means that the owner of a file need not lock a
revision for checkin. This option should <CODE>not</CODE> be
used for files that are shared. Whether default
locking is strict is determined by your system
administrator, but it is normally strict.
</DL>
<A NAME="rcsOptm"></A>
<H3><A NAME="hd_154">Replace log message</A></H3>
<A NAME="cp_-m"></A>
<A NAME="cp_Revision message"></A>
<A NAME="cp_Log message"></A>
<DL><DT>-m<TT>rev</TT>:<TT>msg</TT>
<BR>
<DD>
Replace revision <TT>rev</TT>'s log message with <TT>msg</TT>.
</DL>
<A NAME="rcsOptMu"></A>
<H3><A NAME="hd_155">Do not send Mail</A></H3>
<A NAME="cp_-M"></A>
<A NAME="cp_Mail"></A>
<A NAME="cp_Lock breaking"></A>
<DL><DT>-M
<BR>
<DD>
Do not send mail when breaking somebody else's
lock. This option is not meant for casual use; it
is meant for programs that warn users by other
means, and invoke <CODE>rcs -u</CODE> only as a low-level
lock-breaking operation.
</DL>
<A NAME="rcsOptn"></A>
<H3><A NAME="hd_143">Symbolic name</A></H3>
<A NAME="cp_-n"></A>
<A NAME="cp_Symbolic"></A>
<A NAME="cp_name"></A>
<A NAME="cp_tag"></A>
<DL><DT>-n<TT>name</TT>[:[<TT>rev</TT>]]
<BR>
<DD>
Associate the symbolic name <TT>name</TT> with the branch or
revision <TT>rev</TT>. Delete the symbolic name if both:
and <TT>rev</TT> are omitted; otherwise, print an error message
if <TT>name</TT> is already associated with another
number. If <TT>rev</TT> is symbolic, it is expanded before
association. A <TT>rev</TT> consisting of a branch number
followed by a . stands for the current latest revision
in the branch. A : with an empty <TT>rev</TT> stands
for the current latest revision on the default
branch, normally the trunk. For example,
<PRE>
rcs -n<CODE>name</CODE>: RCS/*
</PRE>
associates <CODE>name</CODE> with the current
latest revision of all the named RCS files; this
contrasts with
<PRE>
rcs -n<CODE>name</CODE>:$ RCS/*
</PRE>
which associates
<CODE>name</CODE> with the revision numbers extracted from keyword
strings in the corresponding working files.
</DL>
<A NAME="rcsOptNu"></A>
<H3><A NAME="hd_156">Override Symbolic name</A></H3>
<A NAME="cp_-N"></A>
<A NAME="cp_Symbolic"></A>
<A NAME="cp_name"></A>
<A NAME="cp_tag"></A>
<A NAME="cp_override Symbolic name"></A>
<DL><DT>-N<TT>name</TT>[:[<TT>rev</TT>]]
<BR>
<DD>
Act like <CODE>-n</CODE>, except override any previous assignment of
<TT>name</TT>.
</DL>
<A NAME="rcsOpto"></A>
<H3><A NAME="hd_157">Delete revisions</A></H3>
<A NAME="cp_-o"></A>
<A NAME="cp_Delete revision"></A>
<DL><DT>-o<TT>range</TT>
<BR>
<DD>
deletes ("outdates") the revisions given by <TT>range</TT>.
A range consisting of a single revision number
means that revision. A range consisting of a
branch number means the latest revision on that
branch. A range of the form <CODE><TT>rev1</TT>:<TT>rev2</TT></CODE> means
revisions <CODE>rev1</CODE> to <CODE>rev2</CODE> on the same branch,
<CODE>:<TT>rev</TT></CODE> means from the beginning of the branch
containing <TT>rev</TT> up to and including <TT>rev</TT>,
and <CODE>rev:</CODE> means from revision <CODE>rev</CODE> to the
end of the branch containing <CODE>rev</CODE> . None of the
outdated revisions can have branches or locks.
</DL>
<A NAME="rcsOptq"></A>
<H3><A NAME="hd_158">Quiet mode</A></H3>
<A NAME="cp_-q"></A>
<A NAME="cp_Quiete mode"></A>
<DL><DT>-q
<BR>
<DD>
Run quietly; do not print diagnostics.
</DL>
<A NAME="rcsOptIu"></A>
<H3><A NAME="hd_159">Interactive</A></H3>
<A NAME="cp_-I"></A>
<A NAME="cp_Interactiv"></A>
<DL><DT>-I
<BR>
<DD>
Run interactively, even if the standard input is
not a terminal.
</DL>
<A NAME="rcsOpts"></A>
<H3><A NAME="hd_160">States</A></H3>
<A NAME="cp_-s"></A>
<A NAME="cp_States"></A>
<DL><DT>-s<TT>state</TT>:[<TT>rev</TT>]
<BR>
<DD>
Set the state attribute of the revision <TT>rev</TT> to
<TT>state</TT>. If <TT>rev</TT> is a branch number, assume the latest
revision on that branch. If <TT>rev</TT> is omitted,
assume the latest revision on the default branch.
Any identifier is acceptable for <TT>state</TT> . A useful
set of states is Exp (for experimental), Stab (for
stable), and Rel (for released). By default, <A HREF="#ciOpts">ciOpts</A>
sets the state of a revision to Exp.
</DL>
<A NAME="rcsOptt"></A>
<H3><A NAME="hd_161">Descriptive Text</A></H3>
<A NAME="cp_-t"></A>
<A NAME="cp_Descriptive"></A>
<DL><DT>-t<TT>file</TT>
<BR>
<DD>
Write descriptive text from the contents of the
named <TT>file</TT> into the RCS file, deleting the existing
text. The <TT>file</TT> pathname cannot begin with <CODE>-</CODE>.
If <TT>file</TT> is omitted, obtain the text from standard
input, terminated by end-of-file or by a line containing.
by itself. Prompt for the text if interaction is possible;
see <CODE>-I</CODE> <A HREF="#rcsOptIu">rcsOptIu</A>. With <CODE>-i</CODE>, descriptive
text is obtained even if <CODE>-t</CODE> is not given.
<DT>-t-<TT>string</TT>
<BR>
<DD>Write descriptive text from the <TT>string</TT> into the RCS
file, deleting the existing text.
</DL>
<A NAME="rcsOptTu"></A>
<H3><A NAME="hd_162">Modification Time</A></H3>
<A NAME="cp_-T"></A>
<A NAME="cp_Modification Time"></A>
<DL><DT>-T
<BR>
<DD>
Preserve the modification time on the RCS file
unless a revision is removed. This option can sup-
press extensive recompilation caused by a <CODE>make</CODE>
dependency of some copy of the working file on the
RCS file. Use this option with care; it can suppress
recompilation even when it is needed, i.e.
when a change to the RCS file would mean a change
to keyword strings in the working file.
</DL>
<A NAME="rcsOptV"></A>
<H3><A NAME="hd_163">Version</A></H3>
<A NAME="cp_-V"></A>
<A NAME="cp_Version"></A>
<A NAME="cp_Emulation of RCS"></A>
<DL><DT>-V
<BR>
<DD>
Print RCS's version number.
<DT>-V<TT>n</TT>
<BR>
<DD>Emulate RCS version <TT>n</TT>. See <A HREF="#coOptV">coOptV</A> for details.
</DL>
<A NAME="rcsOptx"></A>
<H3><A NAME="hd_164">Suffixes</A></H3>
<A NAME="cp_-x"></A>
<A NAME="cp_Suffixes"></A>
<DL><DT>-x<TT>suffixes</TT>
<BR>
<DD>
Use <TT>suffixes</TT> to characterize RCS files. See <A HREF="#ciOptx">ciOptx</A>.
</DL>
<A NAME="rcsOptz"></A>
<H3><A NAME="hd_165">Time Zone</A></H3>
<A NAME="cp_-z"></A>
<A NAME="cp_Time Zone"></A>
<DL><DT>-z<TT>zone</TT>
<BR>
<DD>
Use <TT>zone</TT> as the default time zone. This option has
no effect; it is present for compatibility with
other RCS commands.
</DL>
<A NAME="rcsCompatibility"></A>
<H3><A NAME="hd_46">Compatibility</A></H3>
<A NAME="cp_Compatibility"></A>
The <CODE>-b<TT>rev</TT></CODE> option generates an RCS file that cannot be
parsed by RCS version 3 or earlier.
<P>The <CODE>-k<TT>subst</TT></CODE> options (except <CODE>-kkv</CODE>) generate an RCS file
that cannot be parsed by RCS version 4 or earlier.
<P>Use rcs <CODE>-V<TT>n</TT></CODE> to make an RCS file acceptable to RCS version
<TT>n</TT> by discarding information that would confuse version <TT>n</TT>.
<P>RCS version 5.5 and earlier does not support the <CODE>-x</CODE>
option, and requires a <CODE>,v</CODE> suffix on an RCS pathname.
<A NAME="rcsFiles"></A>
<H3><A NAME="hd_47">Files</A></H3>
<A NAME="cp_Files"></A>
<P>rcs accesses files much as <CODE>ci</CODE> does, except that it uses
the effective user for all accesses, it does not write the
working file or its directory, and it does not even read
<A NAME="rcsEnv"></A>
<H2><A NAME="hd_48">Environment</A></H2>
<A NAME="cp_Environment"></A>
<DL><DT>RCSINIT
<BR>
<DD>options prepended to the argument list, separated by spaces.
See <A HREF="#ciEnv">ciEnv</A> for details.
</DL>
<A NAME="rcsDiag"></A>
<H2><A NAME="hd_49">Diagnostics</A></H2>
The RCS pathname and the revisions outdated are written to
the diagnostic output. The exit status is zero if and
only if all operations were successful.
<A NAME="rcsBugs"></A>
<H2><A NAME="hd_50">Bugs</A></H2>
A catastrophe (e.g. a system crash) can cause RCS to leave
behind a semaphore file that causes later invocations of
RCS to claim that the RCS file is in use. To fix this,
remove the semaphore file. A semaphore file's name typically
begins with <TT>,</TT> or ends with <TT>_</TT>.
<P>The separator for revision ranges in the <CODE>-o</CODE> option used to
be <TT>-</TT> instead of <TT>:</TT>, but this leads to confusion when
symbolic names contain <TT>-</TT>. For backwards compatibility
<CODE>rcs -o</CODE> still supports the old - separator, but it warns about
this obsolete use.
<P>Symbolic names need not refer to existing revisions or
branches. For example, the <CODE>-o</CODE> option does not remove symbolic
names for the outdated revisions; you must use <CODE>-n</CODE> to
remove the names.
<A NAME="ident"></A>
<H1><A NAME="hd_51">ident -- identify RCS keywords</A></H1>
<A NAME="cp_ident"></A>
<A NAME="cp_identify Keywords"></A>
<A NAME="cp_Keywords"></A>
<UL>
<LI><A HREF="#identIntro">Introduction to <CODE>rcs</CODE>.</A>
<LI><A HREF="#identOptions">command line options of <CODE>rcs</CODE>.</A>
<LI><A HREF="#identKeywords">Keywords.</A>
</UL>
<A NAME="identIntro"></A>
<H2><A NAME="hd_52">Description</A></H2>
<P>Ident searches for all instances of the pattern
<CODE>$keyword: text $</CODE> in the named
files or, if no files are named, the standard input.
<P>These patterns are normally inserted automatically by the
RCS command <CODE>co</CODE> (<A HREF="#coKeyword">coKeyword</A>), but can also
be inserted manually. The option
<CODE>-q</CODE>(See <A HREF="#identOptq">identOptq</A>) suppresses the
warning given if there are no patterns in a file.
The option <CODE>-V</CODE>(See <A HREF="#identOptV">identOptV</A>) prints ident's version
number.
<P>ident works on text files as well as object files and
dumps. For example, if the C program in f.c contains:
<PRE>
#include <stdio.h>
static char const rcsid[] =
"$Id: f.c,v 5.4 1993/11/09 17:40:15 eggert Exp $";
int main() { return printf("%s\n", rcsid) == EOF; }
</PRE>
<P>and f.c is compiled into f.o, then the command
<PRE>
ident f.c f.o
</PRE>
<P>will output
<PRE>
f.c:
$Id: f.c,v 5.4 1993/11/09 17:40:15 eggert Exp $
f.o:
$Id: f.c,v 5.4 1993/11/09 17:40:15 eggert Exp $
</PRE>
<P>If a C program defines a string like rcsid above but does
not use it, <CODE>lint</CODE> may complain, and some C compilers
will optimize away the string. The most reliable solution
is to have the program use the rcsid string, as shown in
the example above.
<P>ident finds all instances of the <CODE>$keyword: text $</CODE>
pattern, even if <CODE>keyword</CODE> is not actually an RCS-supported keyword.
This gives you information about nonstandard keywords like
<CODE>$XConsortium$</CODE>.
<A NAME="identOptions"></A>
<H2><A NAME="hd_53">Command line options of ident</A></H2>
<P>Overview off all options which can be given to <CODE>rcs</CODE>
<P><CODE>Synopsis</CODE>: ident [options] [ file ··· ]
<UL>
<LI><A HREF="#identOptq">-q Quiet mode.</A>
<LI><A HREF="#identOptV">-V Version</A>
</UL>
<A NAME="identOptq"></A>
<H3><A NAME="hd_166">Quiet mode</A></H3>
<A NAME="cp_-q"></A>
<A NAME="cp_Quiete mode"></A>
<DL><DT>-q
<BR>
<DD>
Suppress warning given if there are no patterns in a file.
</DL>
<A NAME="identOptV"></A>
<H3><A NAME="hd_167">Version</A></H3>
<A NAME="cp_-V"></A>
<A NAME="cp_Version"></A>
<DL><DT>-V
<BR>
<DD>
Print ident's version number.
</DL>
<A NAME="identKeywords"></A>
<H2><A NAME="hd_54">Keywords</A></H2>
<A NAME="cp_Keywords"></A>
The maintained list of keywords of <CODE>co</CODE> you'll find
in <A HREF="#coKeyword">coKeyword</A>.
<BR><BR>All times are given in Coordinated Universal Time
(UTC, sometimes called GMT) by default, but if the files
were checked out with <CODE>co</CODE>'s <CODE>-z<TT>zone</TT></CODE> (See <A HREF="#coOptz">coOptz</A>)
option, times are given with a numeric time zone indication appended.
<A NAME="rcsclean"></A>
<H1><A NAME="hd_55">rcsclean -- clean up working files</A></H1>
<A NAME="cp_rcsclean"></A>
<A NAME="cp_clean up"></A>
<A NAME="cp_working files"></A>
<UL>
<LI><A HREF="#rcscleanIntro">Introduction to <CODE>rcsclean</CODE>.</A>
<LI><A HREF="#rcscleanOptions">command line options of <CODE>rcsclean</CODE>.</A>
<LI><A HREF="#rcscleanExamples">Examples in using <CODE>rcsclean</CODE>.</A>
<LI><A HREF="#rcscleanFiles">Files.</A>
<LI><A HREF="#rcscleanEnv">The Environment which can change the behaviour of much of the RCS commands.</A>
<LI><A HREF="#rcscleanDiag">Diagnostic output of <CODE>rcsclean</CODE>.</A>
<LI><A HREF="#rcscleanBugs">Bugs.</A>
</UL>
<A NAME="rcscleanIntro"></A>
<H2><A NAME="hd_56">Description</A></H2>
<P><CODE>rcsclean</CODE> removes files that are not being worked on.
<CODE>rcsclean -u</CODE> (<A HREF="#rcscleanOptu">rcscleanOptu</A>) also unlocks and removes
files that are being worked on but have not changed.
<P>For each <TT>file</TT> given, rcsclean compares the working file
and a revision in the corresponding RCS file. If it finds
a difference, it does nothing. Otherwise, it first
unlocks the revision if the <CODE>-u</CODE> (See <A HREF="#rcscleanOptu">rcscleanOptu</A>
option is given, and then
removes the working file unless the working file is
writable and the revision is locked. It logs its actions
by outputting the corresponding <CODE>rcs -u</CODE> (See <A HREF="#rcsOptu">rcsOptu</A>)
and <CODE>rm -f</CODE> commands on the standard output.
<P>Files are paired as explained in <A HREF="#ciFiles">ciFiles</A>.
If no <TT>file</TT> is
given, all working files in the current directory are
cleaned. Pathnames matching an RCS suffix denote RCS
files; all others denote working files.
<P>The number of the revision to which the working file is
compared may be attached to any of the options <CODE>-n</CODE>,
<CODE>-q</CODE>, <CODE>-r</CODE>, or <CODE>-u</CODE>.
If no revision number is specified, then if the <CODE>-u</CODE>
option is given and the caller has one revision locked,
rcsclean uses that revision; otherwise rcsclean uses the
latest revision on the default branch, normally the root.
<P><CODE>rcsclean</CODE> is useful for clean targets in makefiles.
See <A HREF="#rcsdiff">rcsdiff</A>, which prints out the differences, and
<CODE>ci</CODE> (<A HREF="#ciIntro">ciIntro</A>), which normally reverts to the
previous revision if a file was not changed.
<A NAME="rcscleanOptions"></A>
<H2><A NAME="hd_57">Command line options of rcsclean</A></H2>
<P>Overview off all options which can be given to <CODE>rcsclean</CODE>
<P><CODE>Synopsis</CODE>: rcsclean [options] [ file ··· ]
<UL>
<LI><A HREF="#rcscleanOptk">-k Keyword substitution.</A>
<LI><A HREF="#rcscleanOptn">-n Do not unlock or remove.</A>
<LI><A HREF="#rcscleanOptq">-q Quiet mode.</A>
<LI><A HREF="#rcscleanOptr">-r Revision for comparison.</A>
<LI><A HREF="#rcscleanOptT">-T Modification time.</A>
<LI><A HREF="#rcscleanOptu">-u unlock revisions.</A>
<LI><A HREF="#rcscleanOptV">-V Version; Emulation RCS Version.</A>
<LI><A HREF="#rcscleanOptx">-x Suffixes.</A>
<LI><A HREF="#rcscleanOptz">-z Time zone.</A>
</UL>
<A NAME="rcscleanOptk"></A>
<H3><A NAME="hd_169">Keyword substitution</A></H3>
<A NAME="cp_-k"></A>
<A NAME="cp_Keyword"></A>
<DL><DT>-k<TT>subst</TT>
<BR>
<DD>
Use <TT>subst</TT> style keyword substitution when retrieving
the revision for comparison. See <A HREF="#coKeyword">coKeyword</A>
for details.
</DL>
<A NAME="rcscleanOptn"></A>
<H3><A NAME="hd_170">No removing</A></H3>
<A NAME="cp_-n"></A>
<A NAME="cp_remove"></A>
<A NAME="cp_unlock"></A>
<DL><DT>-n<TT>rev</TT>
<BR>
<DD>
Do not actually remove any files or unlock any
revisions. Using this option will tell you what
<CODE>rcsclean</CODE> would do without actually doing it.
</DL>
<A NAME="rcscleanOptq"></A>
<H3><A NAME="hd_171">Quiet mode</A></H3>
<A NAME="cp_-q"></A>
<A NAME="cp_Quiet"></A>
<DL><DT>-q<TT>rev</TT>
<BR>
<DD>
Do not log the actions taken on standard output.
</DL>
<A NAME="rcscleanOptr"></A>
<H3><A NAME="hd_172">Revision for comparison</A></H3>
<A NAME="cp_-r"></A>
<A NAME="cp_Revision"></A>
<A NAME="cp_comparison"></A>
<DL><DT>-r<TT>rev</TT>
<BR>
<DD>
This option has no effect other than specifying the
revision for comparison.
</DL>
<A NAME="rcscleanOptT"></A>
<H3><A NAME="hd_173">Modification time</A></H3>
<A NAME="cp_-T"></A>
<A NAME="cp_Modification"></A>
<A NAME="cp_time/date"></A>
<DL><DT>-T
<BR>
<DD>
Preserve the modification time on the RCS file even
if the RCS file changes because a lock is removed.
This option can suppress extensive recompilation
caused by a <CODE>make</CODE> dependency of some other copy
of the working file on the RCS file. Use this
option with care; it can suppress recompilation
even when it is needed, i.e. when the lock removal
would mean a change to keyword strings in the other
working file.
</DL>
<A NAME="rcscleanOptu"></A>
<H3><A NAME="hd_168">Unlock revision</A></H3>
<A NAME="cp_-u"></A>
<A NAME="cp_Unlock revision"></A>
<DL><DT>-u<TT>rev</TT>
<BR>
<DD>
Unlock the revision if it is locked and no difference is found.
</DL>
<A NAME="rcscleanOptV"></A>
<H3><A NAME="hd_174">Version and Emulation</A></H3>
<A NAME="cp_-V"></A>
<A NAME="cp_RCS Version"></A>
<A NAME="cp_Emulation of RCS Version"></A>
<DL><DT>-V
<BR>
<DD>
Print RCS's version number.
<DT>-V<TT>n</TT>
<BR>
<DD>Emulate RCS version <TT>n</TT>. See <A HREF="#coOptV">coOptV</A> for details.
</DL>
<A NAME="rcscleanOptx"></A>
<H3><A NAME="hd_175">Suffixes</A></H3>
<A NAME="cp_-x"></A>
<A NAME="cp_Suffixes"></A>
<DL><DT>-x<TT>suffixes</TT>
<BR>
<DD>
Use <TT>suffixes</TT> to characterize RCS files. See <A HREF="#ciOptx">ciOptx</A>
for details.
</DL>
<A NAME="rcscleanOptz"></A>
<H3><A NAME="hd_176">Time zone</A></H3>
<A NAME="cp_-z"></A>
<A NAME="cp_Time zone"></A>
<DL><DT>-z<TT>zone</TT>
<BR>
<DD>
<CODE>-z<TT>zone</TT></CODE> Use <TT>zone</TT> as the time zone for keyword substitution;
see <A HREF="#coOptz">coOptz</A> for details.
</DL>
<A NAME="rcscleanExamples"></A>
<H2><A NAME="hd_58">Examples</A></H2>
<A NAME="cp_Examples"></A>
<PRE>
rcsclean *.c *.h
</PRE>
<P>removes all working files ending in .c or .h that were not
changed since their checkout.
<PRE>
rcsclean
</PRE>
<P>removes all working files in the current directory that
were not changed since their checkout.
<A NAME="rcscleanFiles"></A>
<H2><A NAME="hd_59">Files</A></H2>
<A NAME="cp_Files"></A>
<P>rcsclean accesses files much as <CODE>ci</CODE> (<A HREF="#ciFiles">ciFiles</A>)does.
<A NAME="rcscleanEnv"></A>
<H2><A NAME="hd_60">Environment</A></H2>
<A NAME="cp_Environment"></A>
<DL><DT>RCSINIT
<BR>
<DD>options prepended to the argument list, separated by spaces.
See <A HREF="#ciEnv">ciEnv</A> for details.
</DL>
<A NAME="rcscleanDiag"></A>
<H2><A NAME="hd_61">Diagnostics</A></H2>
The exit status is zero if and only if all operations were
successful. Missing working files and RCS files are
silently ignored.
<A NAME="rcscleanBugs"></A>
<H2><A NAME="hd_62">Bugs</A></H2>
At least one <TT>file</TT> must be given in older Unix versions
that do not provide the needed directory scanning operations.
<A NAME="rcsdiff"></A>
<H1><A NAME="hd_63">rcsdiff -- compare RCS revisions</A></H1>
<A NAME="cp_rcsdiff"></A>
<A NAME="cp_compare revisions"></A>
<UL>
<LI><A HREF="#rcsdiffIntro">Introduction to <CODE>rcsdiff</CODE>.</A>
<LI><A HREF="#rcsdiffOptions">command line options of <CODE>rcsdiff</CODE>.</A>
<LI><A HREF="#rcsdiffExamples">Examples in using <CODE>rcsdiff</CODE>.</A>
<LI><A HREF="#rcsdiffEnv">The Environment which can change the behaviour of much of the RCS commands.</A>
<LI><A HREF="#rcsdiffDiag">Diagnostic output of <CODE>rcsdiff</CODE>.</A>
</UL>
<A NAME="rcsdiffIntro"></A>
<H2><A NAME="hd_64">Description</A></H2>
<P>rcsdiff runs <CODE>diff</CODE> to compare two revisions of each RCS
file given.
<P>Pathnames matching an RCS suffix denote RCS files; all
others denote working files. Names are paired as
explained in <A HREF="#ciFiles">ciFiles</A>.
<A NAME="rcsdiffOptions"></A>
<H2><A NAME="hd_65">Command line options of rcsdiff</A></H2>
<P>Overview off all options which can be given to <CODE>rcsdiff</CODE>
<P><CODE>Synopsis</CODE>: rcsdiff [options] [<CODE>-r<TT>rev1</TT></CODE>] [<CODE>-r<TT>rev2</TT></CODE>] [<CODE>diff options</CODE>] [ file ··· ]
<UL>
<LI><A HREF="#rcsdiffOptk">-k Keyword substitution.</A>
<LI><A HREF="#rcsdiffOptq">-q Quiet mode.</A>
<LI><A HREF="#rcsdiffOptr">-r Revision for comparison.</A>
<LI><A HREF="#rcsdiffOptT">-T Modification time.</A>
<LI><A HREF="#rcsdiffOptV">-V Version; Emulation RCS Version.</A>
<LI><A HREF="#rcsdiffOptx">-x Suffixes.</A>
</UL>
<A NAME="rcsdiffOptk"></A>
<H3><A NAME="hd_177">Keyword substitution</A></H3>
<A NAME="cp_-k"></A>
<A NAME="cp_Keyword"></A>
<DL><DT>-k<TT>subst</TT>
<BR>
<DD>
<CODE>-k<TT>subst</TT></CODE> affects keyword substitution when extracting
revisions, as described in <A HREF="#coOptk">coOptk</A>; for example,
<CODE>-kk -r1.1 -r1.2</CODE> ignores differences in keyword values
when comparing revisions <CODE>1.1</CODE> and <CODE>1.2</CODE>.
To avoid excess output from locker name substitution,
<CODE>-kkvl</CODE> is assumed if
<OL>
<DT>.&larrow.at most one revision option is given,
<BR>
<DT>.&larrow.no <CODE>-k</CODE> option is given,
<BR>
<DT>.&larrow.<CODE>-kkv</CODE> is the default keyword substitution, and
<BR>
<DT>.&larrow.the working file's mode would be produced by <CODE>co -l</CODE>.
<BR>
</DL>
</DL>
<A NAME="rcsdiffOptq"></A>
<H3><A NAME="hd_178">Quiet mode</A></H3>
<A NAME="cp_-q"></A>
<A NAME="cp_Quiet"></A>
<DL><DT>-q<TT>rev</TT>
<BR>
<DD>
The option -q suppresses diagnostic output.
</DL>
<A NAME="rcsdiffOptr"></A>
<H3><A NAME="hd_179">Revision for comparison</A></H3>
<A NAME="cp_-r"></A>
<A NAME="cp_Revision"></A>
<A NAME="cp_comparison"></A>
<DL><DT>-r<TT>rev1</TT> -r<TT>rev2</TT>
<BR>
<DD>
Zero, one, or two revisions may be specified with <CODE>-r</CODE>.
If both <TT>rev1</TT> and <TT>rev2</TT> are omitted, rcsdiff compares the
latest revision on the default branch (by default the
trunk) with the contents of the corresponding working
file. This is useful for determining what you changed
since the last checkin.
<P>If <TT>rev1</TT> is given, but <TT>rev2</TT> is omitted, rcsdiff compares
revision <TT>rev1</TT> of the RCS file with the contents of the
corresponding working file.
<P>If both <TT>rev1</TT> and <TT>rev2</TT> are given, rcsdiff compares
revisions <TT>rev1</TT> and <TT>rev2</TT> of the RCS file.
<P>Both <TT>rev1</TT> and <TT>rev2</TT> may be given numerically or symbolically.
</DL>
<A NAME="rcsdiffOptT"></A>
<H3><A NAME="hd_180">Modification time</A></H3>
<A NAME="cp_-T"></A>
<A NAME="cp_Modification"></A>
<A NAME="cp_time/date"></A>
<DL><DT>-T
<BR>
<DD>
For details See <A HREF="#coOptT">coOptT</A>.
</DL>
<A NAME="rcsdiffOptV"></A>
<H3><A NAME="hd_181">Version and Emulation</A></H3>
<A NAME="cp_-V"></A>
<A NAME="cp_RCS Version"></A>
<A NAME="cp_Emulation of RCS Version"></A>
<DL><DT>-V
<BR>
<DD>
Print RCS's version number.
<DT>-V<TT>n</TT>
<BR>
<DD>Emulate RCS version <TT>n</TT>. See <A HREF="#coOptV">coOptV</A> for details.
</DL>
<A NAME="rcsdiffOptx"></A>
<H3><A NAME="hd_182">Suffixes</A></H3>
<A NAME="cp_-x"></A>
<A NAME="cp_Suffixes"></A>
<DL><DT>-x<TT>suffixes</TT>
<BR>
<DD>
Use <TT>suffixes</TT> to characterize RCS files. See <A HREF="#ciOptx">ciOptx</A>
for details.
</DL>
<A NAME="rcsdiffExamples"></A>
<H2><A NAME="hd_66">Examples</A></H2>
<A NAME="cp_Examples"></A>
<PRE>
rcsdiff *.c *.h
</PRE>
<P>removes all working files ending in .c or .h that were not
changed since their checkout.
<PRE>
rcsdiff
</PRE>
<P>removes all working files in the current directory that
were not changed since their checkout.
<A NAME="rcsdiffEnv"></A>
<H2><A NAME="hd_67">Environment</A></H2>
<A NAME="cp_Environment"></A>
<DL><DT>RCSINIT
<BR>
<DD>options prepended to the argument list, separated by spaces.
See <A HREF="#ciEnv">ciEnv</A> for details.
</DL>
<A NAME="rcsdiffDiag"></A>
<H2><A NAME="hd_68">Diagnostics</A></H2>
Exit status is 0 for no differences during any comparison,
1 for some differences, 2 for trouble.
<A NAME="rcsmerge"></A>
<H1><A NAME="hd_69">rcsmerge -- merge RCS versions</A></H1>
<A NAME="cp_rcsmerge"></A>
<A NAME="cp_merge revisions"></A>
<UL>
<LI><A HREF="#rcsmergeIntro">Introduction to <CODE>rcs</CODE>.</A>
<LI><A HREF="#rcsmergeOptions">command line options of <CODE>rcs</CODE>.</A>
<LI><A HREF="#rcsmergeExamples">Examples of <CODE>rcsmerge</CODE>.</A>
<LI><A HREF="#rcsmergeEnv">The Environment which can change the behaviour of much of the RCS commands.</A>
<LI><A HREF="#rcsmergeDiag">Diagnostic output of <CODE>rcs</CODE>.</A>
</UL>
<A NAME="rcsmergeIntro"></A>
<H2><A NAME="hd_70">Description</A></H2>
<P>rcsmerge incorporates the changes between two revisions of
an RCS file into the corresponding working file.
<P>Pathnames matching an RCS suffix denote RCS files; all
others denote working files. Names are paired as
explained in <A HREF="#ciFiles">ciFiles</A>.
<P>At least one revision must be specified with one of the
options described below, usually <CODE>-r</CODE>.
At most two revisions may be specified. If only one
revision is specified, the latest revision on the
default branch (normally the highest branch on the
trunk) is assumed for the second revision.
Revisions may be specified numerically or symbolically.
<P>rcsmerge prints a warning if there are overlaps, and
delimits the overlapping regions as explained in <A HREF="#merge">merge</A>.
The command is useful for incorporating changes into a
checked-out revision.
<A NAME="rcsmergeOptions"></A>
<H2><A NAME="hd_71">Command line options of rcsmerge</A></H2>
<P>Overview off all options which can be given to <CODE>rcsmerge</CODE>
<P><CODE>Synopsis</CODE>: rcsmerge [options] file ···
<UL>
<LI><A HREF="#rcsmergeOptA">-A Output conflicts the -A style.</A>
<LI><A HREF="#rcsmergeOptE">-E specify Conflict style</A>
<LI><A HREF="#rcsmergeOptk">-k Keyword substitution.</A>
<LI><A HREF="#rcsmergeOptp">-p send to stdout.</A>
<LI><A HREF="#rcsmergeOptT">-T Modification time.</A>
<LI><A HREF="#rcsmergeOptV">-V Version; Emulation of RCS Version.</A>
<LI><A HREF="#rcsmergeOptx">-x Suffixes.</A>
<LI><A HREF="#rcsmergeOptz">-z Time zone.</A>
</UL>
<A NAME="rcsmergeOptA"></A>
<H3><A NAME="hd_183">Output conflicts</A></H3>
<A NAME="cp_-A"></A>
<A NAME="cp_diff3"></A>
<A NAME="cp_diff"></A>
<DL><DT>-A
<BR>
<DD>
Output conflicts using the <CODE>-A</CODE> style of <CODE>diff3</CODE>, if
supported by <CODE>diff3</CODE>. This merges all changes leading
from <TT>file2</TT> to <TT>file3</TT> into <TT>file1</TT>, and generates
the most verbose output.
</DL>
<A NAME="rcsmergeOptE"></A>
<H3><A NAME="hd_184">Less information</A></H3>
<A NAME="cp_-e"></A>
<A NAME="cp_-E"></A>
<A NAME="cp_conflict"></A>
<DL><DT>-E -e
<BR>
<DD>
These options specify conflict styles that generate
less information than <CODE>-A</CODE>. See <CODE>diff3</CODE> for
details. The default is <CODE>-E</CODE>. With <CODE>-e</CODE>, <CODE>rcsmerge</CODE>
does not warn about conflicts.
</DL>
<A NAME="rcsmergeOptk"></A>
<H3><A NAME="hd_185">Keyword substitution</A></H3>
<A NAME="cp_-k"></A>
<A NAME="cp_Keyword"></A>
<DL><DT>-k<TT>subst</TT>
<BR>
<DD>
Use <TT>subst</TT> style keyword substitution.
See <A HREF="#coKeyword">coKeyword</A> for details.
For example, <CODE>-kk -r1.1 -r1.2</CODE> ignores
differences in keyword values when merging the
changes from <CODE>1.1</CODE> to <CODE>1.2</CODE>. It normally
does not make sense to merge binary files as if
they were text, so <CODE>rcsmerge</CODE> refuses to merge
files if <CODE>-kb</CODE> expansion is used.
</DL>
<A NAME="rcsmergeOptp"></A>
<H3><A NAME="hd_186">Send to standard out</A></H3>
<A NAME="cp_-p"></A>
<A NAME="cp_Output"></A>
<A NAME="cp_send result to standard out."></A>
<DL><DT>-p[<TT>rev</TT>]
<BR>
<DD>
Send the result to standard output instead of over-
writing the working file.
</DL>
<A NAME="rcsmergeOptT"></A>
<H3><A NAME="hd_187">Modification Time</A></H3>
<A NAME="cp_-T"></A>
<A NAME="cp_Modification Time"></A>
<DL><DT>-T
<BR>
<DD>
This option has no effect; it is present for compatibility
with other RCS commands.
</DL>
<A NAME="rcsmergeOptV"></A>
<H3><A NAME="hd_188">Version</A></H3>
<A NAME="cp_-V"></A>
<A NAME="cp_Version"></A>
<A NAME="cp_Emulation of RCS"></A>
<DL><DT>-V
<BR>
<DD>
Print RCS's version number.
<DT>-V<TT>n</TT>
<BR>
<DD>Emulate RCS version <TT>n</TT>. See <A HREF="#coOptV">coOptV</A> for details.
</DL>
<A NAME="rcsmergeOptx"></A>
<H3><A NAME="hd_189">Suffixes</A></H3>
<A NAME="cp_-x"></A>
<A NAME="cp_Suffixes"></A>
<DL><DT>-x<TT>suffixes</TT>
<BR>
<DD>
Use <TT>suffixes</TT> to characterize RCS files. See <A HREF="#ciOptx">ciOptx</A>.
</DL>
<A NAME="rcsmergeOptz"></A>
<H3><A NAME="hd_190">Time Zone</A></H3>
<A NAME="cp_-z"></A>
<A NAME="cp_Time Zone"></A>
<DL><DT>-z<TT>zone</TT>
<BR>
<DD>
Use <TT>zone</TT> as the time zone for keyword substitution.
See <A HREF="#coOptz">coOptz</A> for details.
</DL>
<A NAME="rcsmergeExamples"></A>
<H3><A NAME="hd_72">Examples</A></H3>
<A NAME="cp_Examples"></A>
Suppose you have released revision <CODE>2.8</CODE> of <TT>f.c</TT>. Assume
furthermore that after you complete an unreleased revision
<CODE>3.4</CODE>, you receive updates to release <CODE>2.8</CODE> from someone else.
To combine the updates to <CODE>2.8</CODE> and your changes between <CODE>2.8</CODE>
and <CODE>3.4</CODE>, put the updates to <CODE>2.8</CODE> into file <TT>f.c</TT> and execute
<PRE>
rcsmerge -p -r2.8 -r3.4 f.c >f.merged.c
</PRE>
<P>Then examine <TT>f.merged.c</TT>. Alternatively, if you want to
save the updates to <CODE>2.8</CODE> in the RCS file, check them in as
revision <CODE>2.8.1.1</CODE> and execute <CODE>co -j</CODE>:
<PRE>
ci -r2.8.1.1 f.c
co -r3.4 -j2.8:2.8.1.1 f.c
</PRE>
<P>As another example, the following command undoes the
changes between revision <CODE>2.4</CODE> and <CODE>2.8</CODE> in your currently
checked out revision in <TT>f.c</TT>.
<PRE>
rcsmerge -r2.8 -r2.4 f.c
</PRE>
<P>Note the order of the arguments, and that <TT>f.c</TT> will be
overwritten.
<A NAME="rcsmergeEnv"></A>
<H2><A NAME="hd_73">Environment</A></H2>
<A NAME="cp_Environment"></A>
<DL><DT>RCSINIT
<BR>
<DD>options prepended to the argument list, separated by spaces.
See <A HREF="#ciEnv">ciEnv</A> for details.
</DL>
<A NAME="rcsmergeDiag"></A>
<H2><A NAME="hd_74">Diagnostics</A></H2>
Exit status is 0 for no overlaps, 1 for some overlaps, 2
for trouble.
<A NAME="rlog"></A>
<H1><A NAME="hd_75">rlog -- print log messages</A></H1>
<A NAME="cp_rlog"></A>
<A NAME="cp_log messages"></A>
<A NAME="cp_Information"></A>
<UL>
<LI><A HREF="#rlogIntro">Introduction to <CODE>rlog</CODE>.</A>
<LI><A HREF="#rlogOptions">command line options of <CODE>rlog</CODE>.</A>
<LI><A HREF="#rlogExamples">Examples.</A>
<LI><A HREF="#rlogEnv">The Environment which can change the behaviour of much of the RCS commands.</A>
<LI><A HREF="#rlogDiag">Diagnostic output of <CODE>rlog</CODE>.</A>
<LI><A HREF="#rlogBugs">Bugs.</A>
</UL>
<A NAME="rlogIntro"></A>
<H2><A NAME="hd_76">Description</A></H2>
<P><CODE>rlog</CODE> prints information about RCS files.
<P>Pathnames matching an RCS suffix denote RCS files; all
others denote working files. Names are paired as
explained in <A HREF="#ciFiles">ciFiles</A>.
<P><CODE>rlog</CODE> prints the following information for each RCS file:
RCS pathname, working pathname, head (i.e., the number of
the latest revision on the trunk), default branch, access
list, locks, symbolic names, suffix, total number of revisions,
number of revisions selected for printing, and
descriptive text. This is followed by entries for the
selected revisions in reverse chronological order for each
branch. For each revision, rlog prints revision number,
author, date/time, state, number of lines added/deleted
(with respect to the previous revision), locker of the
revision (if any), and log message. All times are displayed
in Coordinated Universal Time (UTC) by default;
this can be overridden with <CODE>-z</CODE>. Without options,
<CODE>rlog</CODE> prints complete information.
The options below restrict this output.
<A NAME="rlogOptions"></A>
<H2><A NAME="hd_77">Command line options of rlog</A></H2>
<A NAME="cp_Command line options"></A>
<P>Overview off all options which can be given to <CODE>rlog</CODE>
<P><CODE>Synopsis</CODE>: rlog [options] file ···
<UL>
<LI><A HREF="#rlogOptLu">-L Ignore RCS files.</A>
<LI><A HREF="#rlogOptRu">-R Only names of RCS files.</A>
<LI><A HREF="#rlogOpth">-h Only path names.</A>
<LI><A HREF="#rlogOptt">-t Path and discriptive text.</A>
<LI><A HREF="#rlogOptN">-N Do not print symbolic names..</A>
<LI><A HREF="#rlogOptb">-b Information about revisions on default branch.</A>
<LI><A HREF="#rlogOptd">-d Info about revisions with ci-date.</A>
<LI><A HREF="#rlogOptl">-l Print locked revisions only.</A>
<LI><A HREF="#rlogOptr">-r Informations about specified revisions.</A>
<LI><A HREF="#rlogOpts">-s Informations about revisions with state.</A>
<LI><A HREF="#rlogOptw">-w Informations about revisions with user.</A>
<LI><A HREF="#rlogOptTu">-T no effect.</A>
<LI><A HREF="#rlogOptV">-V Version; Emulation of RCS version.</A>
<LI><A HREF="#rlogOptx">-x Suffixes.</A>
<LI><A HREF="#rlogOptz">-z Time zone.</A>
</UL>
<A NAME="rlogOptLu"></A>
<H3><A NAME="hd_191">Ignore RCS files without locks</A></H3>
<A NAME="cp_-L"></A>
<A NAME="cp_no lock"></A>
<A NAME="cp_Ignore"></A>
<DL><DT>-L
<BR>
<DD>
Ignore RCS files that have no locks set. This is convenient
in combination with <CODE>-h</CODE>, <CODE>-l</CODE>, and <CODE>-R</CODE>.
</DL>
<A NAME="rlogOptRu"></A>
<H3><A NAME="hd_192">Only names of RCS files</A></H3>
<A NAME="cp_-R"></A>
<A NAME="cp_Names"></A>
<DL><DT>-R
<BR>
<DD>
Print only the name of the RCS file. This is convenient
for translating a working pathname into an RCS
pathname.
</DL>
<A NAME="rlogOpth"></A>
<H3><A NAME="hd_193">Only pathname</A></H3>
<A NAME="cp_-h"></A>
<A NAME="cp_pathname"></A>
<DL><DT>-h
<BR>
<DD>
Print only the RCS pathname, working pathname, head,
default branch, access list, locks, symbolic names,
and suffix.
</DL>
<A NAME="rlogOptt"></A>
<H3><A NAME="hd_194">Descriptive text</A></H3>
<A NAME="cp_-t"></A>
<A NAME="cp_Descriptive text"></A>
<DL><DT>-t
<BR>
<DD>
Print the same as <CODE>-h</CODE>, plus the descriptive text.
</DL>
<A NAME="rlogOptN"></A>
<H3><A NAME="hd_195">No symbolic name</A></H3>
<A NAME="cp_-N"></A>
<A NAME="cp_no Symbolic name"></A>
<DL><DT>-N
<BR>
<DD>
Do not print the symbolic names.
</DL>
<A NAME="rlogOptb"></A>
<H3><A NAME="hd_196">Default branch</A></H3>
<A NAME="cp_-b"></A>
<A NAME="cp_Default branch"></A>
<DL><DT>-b
<BR>
<DD>
Print information about the revisions on the default
branch, normally the highest branch on the trunk.
</DL>
<A NAME="rlogOptd"></A>
<H3><A NAME="hd_197">Checkin date/time</A></H3>
<A NAME="cp_-d"></A>
<A NAME="cp_Checkin date/time"></A>
<DL><DT>-d<TT>dates</TT>
<BR>
<DD>
Print information about revisions with a checkin date/time
in the ranges given by the semicolon-separated list of
<TT>dates</TT>. A range of the form <TT>d1</TT><<TT>d2</TT> or
<TT>d2</TT>><TT>d1</TT> selects the revisions that were
deposited between <TT>d1</TT> and <TT>d2</TT> exclusive. A range of
the form <<TT>d</TT> or <TT>d</TT>> selects all revisions earlier
than <TT>d</TT>. A range of the form <TT>d</TT>< or ><TT>d</TT> selects
all revisions dated later than <TT>d</TT>. If <CODE><</CODE> or
<CODE>></CODE> is followed by <CODE>=</CODE> then the ranges are inclusive,
not exclusive. A range of the form <TT>d</TT> selects the
single, latest revision dated <TT>d</TT> or earlier. The date/time
strings <TT>d</TT>, <TT>d1</TT>, and <TT>d2</TT> are in the free
format explained in <A HREF="#coOptd">coOptd</A>. Quoting is normally necessary,
especially for <CODE><</CODE> and <CODE>></CODE>. Note that the separator is
a semicolon.
</DL>
<A NAME="rlogOptl"></A>
<H3><A NAME="hd_198">Locked revisions</A></H3>
<A NAME="cp_-l"></A>
<A NAME="cp_Locked revisions"></A>
<DL><DT>-l<TT>lockers</TT>
<BR>
<DD>
Print information about locked revisions only. In
addition, if the comma-separated list <TT>lockers</TT> of login
names is given, ignore all locks other than those held
by the <TT>lockers</TT>. For example,
<PRE>
rlog -L -R -lwft RCS/*
</PRE>
<P>prints the name of RCS files locked by the user <CODE>wft</CODE>.
</DL>
<A NAME="rlogOptr"></A>
<H3><A NAME="hd_199">Informations about revisions</A></H3>
<A NAME="cp_-r"></A>
<A NAME="cp_Information about Revisions"></A>
<DL><DT>-r<TT>revisions</TT>
<BR>
<DD>
prints information about revisions given in the commaseparated
list <CODE>revisions</CODE> of revisions and ranges. A range
<CODE><TT>rev1</TT>:<TT>rev2</TT></CODE> means revisions <TT>rev1</TT> to
<TT>rev2</TT> on the same branch, <CODE>:<TT>rev</TT></CODE> means
revisions from the beginning of the branch up to and including
<TT>rev</TT> , and <CODE><TT>rev</TT>:</CODE> means revisions starting
with <TT>rev</TT> to the end of the branch containing <TT>rev</TT>.
An argument that is a branch means all revisions on that branch.
A range of branches means all revisions on the branches in
that range. A branch followed by a . means the latest revision
in that branch. A bare <CODE>-r</CODE> with no <TT>revisions</TT> means
the latest revision on the default branch, normally the trunk.
</DL>
<A NAME="rlogOpts"></A>
<H3><A NAME="hd_200">Information about Rev. with given state</A></H3>
<A NAME="cp_-s"></A>
<A NAME="cp_Information Rev. given state"></A>
<DL><DT>-s<TT>states</TT>
<BR>
<DD>
prints information about revisions whose state
attributes match one of the states given in the commaseparated
list <TT>states</TT>.
</DL>
<A NAME="rlogOptw"></A>
<H3><A NAME="hd_201">Revisons checked in by user</A></H3>
<A NAME="cp_-w"></A>
<A NAME="cp_Checked in by user"></A>
<DL><DT>-w<TT>logins</TT>
<BR>
<DD>
prints information about revisions checked in by users
with login names appearing in the comma-separated list
<TT>logins</TT>. If <TT>logins</TT> is omitted, the user's login is
assumed.
</DL>
<A NAME="rlogOptTu"></A>
<H3><A NAME="hd_202">Modification Time</A></H3>
<A NAME="cp_-T"></A>
<A NAME="cp_Modification time"></A>
<DL><DT>-T
<BR>
<DD>
This option has no effect; it is present for compatibility
with other RCS commands.
</DL>
<A NAME="rlogOptV"></A>
<H3><A NAME="hd_203">Version and Emulation</A></H3>
<A NAME="cp_-V"></A>
<A NAME="cp_Version"></A>
<A NAME="cp_Emulation"></A>
<DL><DT>-V
<BR>
<DD>
Print RCS's version number.
<DT>-V<TT>n</TT>
<BR>
<DD>Emulate RCS version <TT>n</TT> when generating logs. See
<A HREF="#coOptV">coOptV</A> for more.
</DL>
<A NAME="rlogOptx"></A>
<H3><A NAME="hd_204">Suffixes</A></H3>
<A NAME="cp_-x"></A>
<A NAME="cp_Suffixes"></A>
<DL><DT>-x<TT>suffixes</TT>
<BR>
<DD>
Use <TT>suffixes</TT> to characterize RCS files. See <A HREF="#ciOptx">ciOptx</A> for
details.
</DL>
<A NAME="rlogOptz"></A>
<H3><A NAME="hd_205">Time zone</A></H3>
<A NAME="cp_-z"></A>
<A NAME="cp_Time zone"></A>
Rlog prints the intersection of the revisions selected
with the options <CODE>-d</CODE>, <CODE>-l</CODE>, <CODE>-s</CODE>, and <CODE>-w</CODE>,
intersected with the union of the revisions selected by
<CODE>-b</CODE> and <CODE>-r</CODE>.
<DL><DT>-z<TT>zone</TT>
<BR>
<DD>specifies the date output format, and specifies the
default time zone for <TT>date</TT> in the <CODE>-d<TT>dates</TT></CODE> option.
The <TT>zone</TT> should be empty, a numeric UTC offset, or
the special string <CODE>LT</CODE> for local time. The default
is an empty <TT>zone</TT> , which uses the traditional RCS
format of UTC without any time zone indication and
with slashes separating the parts of the date; oth-
erwise, times are output in ISO 8601 format with
time zone indication. For example, if local time
is January 11, 1990, 8pm Pacific Standard Time,
eight hours west of UTC, then the time is output as
follows:
<PRE>
option time output
-z 1990/01/12 04:00:00 (default)
-zLT 1990-01-11 20:00:00-08
-z+05:30 1990-01-12 09:30:00+05:30
</PRE>
</DL>
<A NAME="rlogExamples"></A>
<H3><A NAME="hd_78">Examples</A></H3>
<A NAME="cp_Examples"></A>
<PRE>
rlog -L -R RCS/*
rlog -L -h RCS/*
rlog -L -l RCS/*
rlog RCS/*
</PRE>
<P>The first command prints the names of all RCS files in the
subdirectory RCS that have locks. The second command
prints the headers of those files, and the third prints
the headers plus the log messages of the locked revisions.
The last command prints complete information.
<A NAME="rlogEnv"></A>
<H3><A NAME="hd_79">Environment</A></H3>
<A NAME="cp_Environment"></A>
<DL><DT>RCSINIT
<BR>
<DD>
options prepended to the argument list, separated
by spaces. See <A HREF="#ciEnv">ciEnv</A> for details.
</DL>
<A NAME="rlogDiag"></A>
<H2><A NAME="hd_80">Diagnostics</A></H2>
The exit status is zero if and only if all operations were
successful.
<A NAME="rlogBugs"></A>
<H2><A NAME="hd_81">Bugs</A></H2>
<A NAME="cp_Bugs"></A>
The separator for revision ranges in the <CODE>-r</CODE> option used to
be <CODE>-</CODE> instead of <CODE>:</CODE>, but this leads to confusion when symbolic
names contain <CODE>-</CODE>. For backwards compatibility
<CODE>rlog -r</CODE> still supports the old <CODE>-</CODE> separator, but it warns about
this obsolete use.
<A NAME="merge"></A>
<H1><A NAME="hd_82">merge -- three-way file merge</A></H1>
<A NAME="cp_merge"></A>
<A NAME="cp_file merge"></A>
<UL>
<LI><A HREF="#mergeIntro">Introduction to <CODE>merge</CODE>.</A>
<LI><A HREF="#mergeOptions">command line options of <CODE>merge</CODE>.</A>
<LI><A HREF="#mergeDiag">Diagnostic output of <CODE>merge</CODE>.</A>
<LI><A HREF="#mergeBugs">Bugs.</A>
</UL>
<A NAME="mergeIntro"></A>
<H2><A NAME="hd_83">Description</A></H2>
<P><CODE>merge</CODE> incorporates all changes that lead from <TT>file2</TT> to
<TT>file3</TT> into <TT>file1</TT>. The result ordinarily goes
into <TT>file1</TT>.
merge is useful for combining separate changes to an original.
Suppose <TT>file2</TT> is the original, and both <TT>file1</TT> and
<TT>file3</TT> are modifications of <TT>file2</TT> . Then merge combines
both changes.
<P>A conflict occurs if both <TT>file1</TT> and <TT>file3</TT> have changes in
a common segment of lines. If a conflict is found, merge
normally outputs a warning and brackets the conflict with
<CODE><<<<<<<</CODE> and <CODE>>>>>>>></CODE> lines. A typical conflict will look
like this:
<PRE>
<<<<<<< file A
lines in file A
=======
lines in file B
>>>>>>> file B
</PRE>
<P>If there are conflicts, the user should edit the result
and delete one of the alternatives.
<A NAME="mergeOptions"></A>
<H2><A NAME="hd_84">Command line options of merge</A></H2>
Overview off all options which can be given to <CODE>merge</CODE>
<P><CODE>Synopsis</CODE>: merge [options] file1 file2 file3
<UL>
<LI><A HREF="#mergeOptA">-A Style of diff3.</A>
<LI><A HREF="#mergeOptE">-E Conflict style.</A>
<LI><A HREF="#mergeOptL">-L Labels.</A>
<LI><A HREF="#mergeOptp">-p Send to standard output.</A>
<LI><A HREF="#mergeOptq">-q Quite mode.</A>
<LI><A HREF="#mergeOptV">-V Version.</A>
</UL>
<A NAME="mergeOptA"></A>
<H3><A NAME="hd_206">Output conflicts</A></H3>
<A NAME="cp_-A"></A>
<A NAME="cp_Output conflicts"></A>
<A NAME="cp_diff3"></A>
<DL><DT>-A
<BR>
<DD>
Output conflicts using the <CODE>-A</CODE> style of <CODE>diff3</CODE>, if
supported by diff3. This merges all changes leading
from <TT>file2</TT> to <TT>file3</TT> into <TT>file1</TT>, and generates
the most verbose output.
</DL>
<A NAME="mergeOptE"></A>
<H3><A NAME="hd_207">Specify conflict styles</A></H3>
<A NAME="cp_-E"></A>
<A NAME="cp_-e"></A>
<A NAME="cp_conflict styles"></A>
<A NAME="cp_diff3"></A>
<DL><DT>-E -e
<BR>
<DD>
These options specify conflict styles that generate
less information than <CODE>-A</CODE>. See <CODE>diff3</CODE> for
details. The default is <CODE>-E</CODE>. With <CODE>-e</CODE>, merge does
not warn about conflicts.
</DL>
<A NAME="mergeOptL"></A>
<H3><A NAME="hd_208">Label</A></H3>
<A NAME="cp_-L"></A>
<DL><DT>-L<TT>label</TT>
<BR>
<DD>
This option may be given up to three times, and
specifies labels to be used in place of the corresponding
file names in conflict reports. That is,
<CODE>merge -L x -L y -L z a b c</CODE> generates output that
looks like it came from files <TT>x</TT>, <TT>y</TT> and <TT>z</TT>instead of
from files <TT>a</TT>, <TT>b</TT> and <TT>c</TT>.
</DL>
<A NAME="mergeOptp"></A>
<H3><A NAME="hd_209">Standard output</A></H3>
<A NAME="cp_-p"></A>
<A NAME="cp_Standard output"></A>
<DL><DT>-p
<BR>
<DD>
Send results to standard output instead of overwriting
<TT>file1</TT>.
</DL>
<A NAME="mergeOptq"></A>
<H3><A NAME="hd_210">Quiet Mode</A></H3>
<A NAME="cp_-q"></A>
<A NAME="cp_Quiet mode"></A>
<DL><DT>-q
<BR>
<DD>
Quiet; do not warn about conflicts.
</DL>
<A NAME="mergeOptV"></A>
<H3><A NAME="hd_211">Version</A></H3>
<A NAME="cp_-V"></A>
<A NAME="cp_Version"></A>
<DL><DT>-V
<BR>
<DD>
Print's version number.
</DL>
<A NAME="mergeDiag"></A>
<H2><A NAME="hd_85">Diagnostics</A></H2>
Exit status is 0 for no conflicts, 1 for some conflicts, 2
for trouble.
<A NAME="mergeBugs"></A>
<H2><A NAME="hd_86">Bugs</A></H2>
It normally does not make sense to merge binary files as
if they were text, but merge tries to do it anyway.
<A NAME="AppendixA"></A>
<H1><A NAME="hd_87">Format of RCS file</A></H1>
<A NAME="cp_rcsfile"></A>
<A NAME="cp_Format of RCS files."></A>
<A NAME="cp_Format"></A>
<UL>
<LI><A HREF="#rcsfileIntro">Discription of the RCS file format.</A>
<LI><A HREF="#rcsfileExample">Example of a revision tree.</A>
</UL>
<A NAME="rcsfileIntro"></A>
<H2><A NAME="hd_212">Description</A></H2>
<P>An RCS file's contents are described by the grammar below.
The text is free format: space, backspace, tab, newline,
vertical tab, form feed, and carriage return (collectively,
<CODE>white space</CODE>) have no significance except in
strings. However, white space cannot appear within an id,
num, or sym, and an RCS file must end with a newline.
<P>Strings are enclosed by @. If a string contains a @, it
must be doubled; otherwise, strings can contain arbitrary
binary data.
<P>The meta syntax uses the following conventions: `|' (bar)
separates alternatives; `{' and `}' enclose optional
phrases; `{' and `}*' enclose phrases that can be repeated
zero or more times; `{' and '}+' enclose phrases that must
appear at least once and can be repeated; Terminal symbols
are in boldface; nonterminal symbols are in <CODE>italic</CODE>.
<PRE>
rcstext ::= admin {delta}* desc {deltatext}*
admin ::= <CODE>head</CODE> {num};
{ branch {num}; }
<CODE>access</CODE> {id}*;
<CODE>symbols</CODE> {sym : num}*;
<CODE>locks</CODE> {id : num}*; {<CODE>strict</CODE> ;}
{ <CODE>comment</CODE> {string}; }
{ <CODE>expand</CODE> {string}; }
{ newphrase }*
delta ::= num
<CODE>date</CODE> num;
<CODE>author</CODE> id;
<CODE>state</CODE> {id};
<CODE>branches</CODE> {num}*;
<CODE>next</CODE> {num};
{ newphrase }*
desc ::= <CODE>desc</CODE> string
deltatext ::= num
<CODE>log</CODE> string
{ newphrase }*
<CODE>text</CODE> string
num ::= {digit | .}+
digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
id ::= {num} idchar {idchar | num }*
sym ::= {digit}* idchar {idchar | digit }*
idchar ::= any visible graphic character except <CODE>special</CODE>
special ::= $ | , | . | : | ; | @
string ::= @{any character, with @ doubled}*@
newphrase ::= id word* ;
word ::= id | num | string | :
</PRE>
<P>Identifiers are case sensitive. Keywords are in lower case
only. The sets of keywords and identifiers can overlap. In most
environments RCS uses the ISO 8859/1 encoding: visible graphic
characters are codes 041-176 and 240-377, and white space
characters are codes 010-015 and 040.
<P>Dates, which appear after the date keyword, are of the form
<CODE>Y.mm.dd.hh.mm.ss</CODE>, where <CODE>Y</CODE> is the year, <CODE>mm</CODE>
the month (01-12), <CODE>dd</CODE> the day (01-31), <CODE>hh</CODE> the hour
(00-23), <CODE>mm</CODE> the minute (00-59), and <CODE>ss</CODE> the
second (00-60). <CODE>Y</CODE> contains just the last two digits of the
year for years from 1900 through 1999, and all the digits
of years thereafter. Dates use the Gregorian calendar; times use
UTC.
<P>The <CODE>newphrase</CODE> productions in the grammar are reserved
for future extensions to the format of RCS files. No
<CODE>newphrase</CODE> will begin with any keyword already in use.
<P>The <CODE>delta</CODE> nodes form a tree. All nodes whose numbers consist
of a single pair (e.g., 2.3, 2.1, 1.3, etc.) are on
the trunk, and are linked through the next field in order
of decreasing numbers. The head field in the <CODE>admin</CODE> node
points to the head of that sequence (i.e., contains the
highest pair). The branch node in the admin node indicates
the default branch (or revision) for most RCS operations.
If empty, the default branch is the highest branch
on the trunk.
<P>All <CODE>delta</CODE> nodes whose numbers consist of 2<CODE>n</CODE> fields
(<CODE>n</CODE>>=2) (e.g., 3.1.1.1, 2.1.2.2, etc.) are linked as follows.
All nodes whose first 2<CODE>n</CODE>-1 number fields are identical are
linked through the next field in order of increasing numbers.
For each such sequence, the <CODE>delta</CODE> node whose number
is identical to the first 2<CODE>n</CODE>-2 number fields of the deltas
on that sequence is called the branchpoint. The branches
field of a node contains a list of the numbers of the
first nodes of all sequences for which it is a branchpoint.
This list is ordered in increasing numbers.
<A NAME="rcsfileExample"></A>
<H2><A NAME="hd_213">Example Revision tree</A></H2>
The following diagram shows an example of an RCS file's
organization.
<PRE>
Head
|
v / \
--------- / \
/ \ / \ | | / \ / \
/ \ / \ | 2.1 | / \ / \
/ \ / \ | | / \ / \
/1.2.1.3\ /1.3.1.1\ | | /1.2.2.2\ /1.2.2.1.1.1\
--------- --------- --------- --------- -------------
^ ^ | ^ ^
| | v | |
/ \ | --------- / \ |
/ \ | \ 1.3 / / \ |
/ \ ---------\ / / \-----------
/1.2.1.1\ \ / /1.2.2.1\
--------- \ / ---------
^ | ^
| v |
| --------- |
| \ 1.2 / |
----------------------\ /---------
\ /
\ /
|
v
---------
\ 1.1 /
\ /
\ /
\ /
</PRE>
<A NAME="AppendixB"></A>
<H1><A NAME="hd_88">Books and related manuals</A></H1>
<UL>
<LI><A HREF="#Feldman">GNU - Make.</A>
<LI><A HREF="#Hunt">GNU - diff.</A>
<LI><A HREF="#Rochkind">SCCS.</A>
<LI><A HREF="#Tichy">Design and implementation of RCS.</A>
<LI><A HREF="#Leblang">Computer-Aided Software Engineering.</A>
<LI><A HREF="#Glasser">The Evolution of a Source Code Control System.</A>
<LI><A HREF="#Brown">The Clear/Caster System.</A>
<LI><A HREF="#Habermann">A Software Development Control System.</A>
<LI><A HREF="#DEC">Code Management System.</A>
<LI><A HREF="#Lampson">Practical Use of a Polymorphic Applicative Language.</A>
<LI><A HREF="#Tichy1">A Data Model for Programming Support Environments and its Application.</A>
<LI><A HREF="#Heckel">A Technique for Isolating Differences Between Files.</A>
<LI><A HREF="#Tichy2">The String-to-String Correction Problem with Block Moves.</A>
</UL>
<A NAME="Feldman"></A>
<H2><A NAME="hd_89">Feldman,Stuart I.</A></H2>
<A NAME="cp_Feldman Stuart I."></A>
<A NAME="cp_Make"></A>
<A NAME="cp_GNU-Make"></A>
<PRE>
Feldman, Stuart I.,
<BR>"Make -- A Program for Maintaining Computer Programs",
Software -- Practice & Experience,
vol. 9, no. 3, pp. 255-265, March 1979.
</PRE>
<A NAME="Hunt"></A>
<H2><A NAME="hd_90">Hunt, James W. and McIlroy, M. D.</A></H2>
<A NAME="cp_Hunt, James W. and McIlroy, M. D."></A>
<A NAME="cp_Diff"></A>
<A NAME="cp_GNU-Diff"></A>
<PRE>
Hunt, James W. and McIlroy, M. D.,
<BR>"An Algorithm for Differential File Comparison",
41, Computing Science Technical Report,
Bell Laboratories, June 1976.
</PRE>
<A NAME="Rochkind"></A>
<H2><A NAME="hd_91">Rochkind, Marc J.</A></H2>
<A NAME="cp_SCCS"></A>
<PRE>
Rochkind, Marc J.
<BR>"The Source Code Control System",
IEEE Transactions on Software Engineering, vol. SE-1,
no. 4, pp. 364-370, Dec. 1975.
</PRE>
<A NAME="Tichy"></A>
<H2><A NAME="hd_92">Tichy, Walter F.</A></H2>
<A NAME="cp_RCS"></A>
<PRE>
Tichy, Walter F.
<BR>"Design, Implementation, and Evaluation of a Revision Control System"
Proceedings of the 6th International Conference on Software Engineering,
pp. 58-67, ACM, IEEE, IPS, NBS, September 1982.
</PRE>
<A NAME="Leblang"></A>
<H2><A NAME="hd_93">Leblang, David B. and Chase, Robert P.</A></H2>
<A NAME="cp_SIGPLAN"></A>
<A NAME="cp_Workstation"></A>
<A NAME="cp_Symposium"></A>
<PRE>
Leblang, David B. and Chase, Robert P.
<BR>"Computer-Aided Software Engineering in a Distributed
Workstation Environment",
SIGPLAN Notices, vol. 19, no. 5, pp. 104-112, May 1984.
Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium
on Practical Software Development Environments.
</PRE>
<A NAME="Glasser"></A>
<H2><A NAME="hd_94">Glasser, Alan L.</A></H2>
<A NAME="cp_SCCS"></A>
<A NAME="cp_Software Quality"></A>
<PRE>
Glasser, Alan L.
<BR>"The Evolution of a Source Code Control System"
Software Engineering Notes, vol. 3, no. 5, pp. 122-125, Nov. 1978.
Proceedings of the Software Quality and Assurance Workshop.
</PRE>
<A NAME="Brown"></A>
<H2><A NAME="hd_95">Brown, H.B.</A></H2>
<A NAME="cp_Clear/Caster"></A>
<PRE>
Brown, H.B.
<BR>"The Clear/Caster System",
Nato Conference on Software Engineering, Rome 1970
</PRE>
<A NAME="Habermann"></A>
<H2><A NAME="hd_96">Habermann, A. Nico</A></H2>
<A NAME="cp_Clear/Caster"></A>
<PRE>
Habermann, A. Nico
<BR>"A Software Development Control System",
Technical Report, Carnegie-Mellon University,
Department of Computer Science, Jan. 1979.
</PRE>
<A NAME="DEC"></A>
<H2><A NAME="hd_97">Code Management System</A></H2>
<A NAME="cp_Code Management System"></A>
<A NAME="cp_DEC"></A>
<PRE>
Digital Equipment Corporation
<BR>"Code Management System",
Document No. EA-23134-82, 1982
</PRE>
<A NAME="Lampson"></A>
<H2><A NAME="hd_98">Lampson, Butler W. and Schmidt, Eric E.</A></H2>
<A NAME="cp_Polymorhpic Applicative Language"></A>
<A NAME="cp_ACM"></A>
<PRE>
Lampson, Butler W. and Schmidt, Eric E.
<BR>"Practical Use of a Polymorphic Applicative Language",
Proceedings of the 10th Symposium on Principles of
Programming Languages,
pp. 237-255, ACM, January 1983.
</PRE>
<A NAME="Tichy1"></A>
<H2><A NAME="hd_99">Tichy, Walter F.</A></H2>
<A NAME="cp_Data Model"></A>
<A NAME="cp_Support"></A>
<A NAME="cp_Environments"></A>
<A NAME="cp_Tools"></A>
<PRE>
Tichy, Walter F.
<BR>"A Data Model for Programming Support Environments and its Application",
Automated Tools for Information System Design and Development, ed.
Hans-Jochen Schneider and Anthony I. Wasserman,
North-Holland Publishing Company, Amsterdam 1982.
</PRE>
<A NAME="Heckel"></A>
<H2><A NAME="hd_100">Heckel, Paul</A></H2>
<A NAME="cp_Differences between files"></A>
<A NAME="cp_Diff"></A>
<A NAME="cp_ACM"></A>
<PRE>
Heckel, Paul
<BR>"A Technique for Isolating Differences Between Files",
Communications of the ACM, vol. 21, no. 4, pp. 264-268, April
1978.
</PRE>
<A NAME="Tichy2"></A>
<H2><A NAME="hd_101">Tichy, Walter F.</A></H2>
<A NAME="cp_String-To-String Correction"></A>
<A NAME="cp_Block moves"></A>
<PRE>
Tichy, Walter F.
<BR>"The String-to-String Correction Problem with Block Moves",
ACM Transactions on Computer Systems, vol. 2, no. 4, pp. 309-321,
Nov. 1984.
</PRE>
<A NAME="Index"></A>
<H1><A NAME="hd_102">Index</A></H1>
<UL>
<LI>-a
<UL>
<LI><A HREF="#hd_145">Append Login names</A>
<LI><A HREF="#hd_146">Append Access list</A>
<LI><A HREF="#hd_183">Output conflicts</A>
<LI><A HREF="#hd_206">Output conflicts</A>
</UL>
<LI>-b
<UL>
<LI><A HREF="#hd_103">Default branch</A>
<LI><A HREF="#hd_196">Default branch</A>
</UL>
<LI>-c
<UL>
<LI><A HREF="#hd_148">Coment leader</A>
</UL>
<LI>-d
<UL>
<LI><A HREF="#hd_118">date</A>
<LI><A HREF="#hd_135">Checkout by date/time</A>
<LI><A HREF="#hd_197">Checkin date/time</A>
</UL>
<LI>-e
<UL>
<LI><A HREF="#hd_147">Erase Login names</A>
<LI><A HREF="#hd_184">Less information</A>
<LI><A HREF="#hd_207">Specify conflict styles</A>
</UL>
<LI>-f
<UL>
<LI><A HREF="#hd_112">force a deposit</A>
<LI><A HREF="#hd_130">Force overwriting working file</A>
</UL>
<LI>-h
<UL>
<LI><A HREF="#hd_193">Only pathname</A>
</UL>
<LI>-i
<UL>
<LI><A HREF="#hd_115">initial check in</A>
<LI><A HREF="#hd_117">interactive mode</A>
<LI><A HREF="#hd_134">Interactive Mode</A>
<LI><A HREF="#hd_144">Initialize RCS File</A>
<LI><A HREF="#hd_159">Interactive</A>
</UL>
<LI>-j
<UL>
<LI><A HREF="#hd_116">just check in</A>
<LI><A HREF="#hd_140">Joining revisions</A>
</UL>
<LI>-k
<UL>
<LI><A HREF="#hd_113">keyword values</A>
<LI><A HREF="#hd_149">Keyword substitution</A>
<LI><A HREF="#hd_169">Keyword substitution</A>
<LI><A HREF="#hd_177">Keyword substitution</A>
<LI><A HREF="#hd_185">Keyword substitution</A>
</UL>
<LI>-kb
<UL>
<LI><A HREF="#hd_131">Keyword strings</A>
</UL>
<LI>-kk
<UL>
<LI><A HREF="#hd_131">Keyword strings</A>
</UL>
<LI>-kkv
<UL>
<LI><A HREF="#hd_131">Keyword strings</A>
</UL>
<LI>-kkvl
<UL>
<LI><A HREF="#hd_131">Keyword strings</A>
</UL>
<LI>-ko
<UL>
<LI><A HREF="#hd_131">Keyword strings</A>
</UL>
<LI>-kv
<UL>
<LI><A HREF="#hd_131">Keyword strings</A>
</UL>
<LI>-l
<UL>
<LI><A HREF="#hd_110">lock a revision</A>
<LI><A HREF="#hd_128">Lock revision</A>
<LI><A HREF="#hd_150">Lock revision</A>
<LI><A HREF="#hd_152">Strict Locking</A>
<LI><A HREF="#hd_191">Ignore RCS files without locks</A>
<LI><A HREF="#hd_198">Locked revisions</A>
<LI><A HREF="#hd_208">Label</A>
</UL>
<LI>-M
<UL>
<LI><A HREF="#hd_119">modification time</A>
<LI><A HREF="#hd_105">log message</A>
<LI><A HREF="#hd_136">Modification time</A>
<LI><A HREF="#hd_154">Replace log message</A>
<LI><A HREF="#hd_155">Do not send Mail</A>
</UL>
<LI>-n
<UL>
<LI><A HREF="#hd_107">symbolic name</A>
<LI><A HREF="#hd_108">replace symbolic name</A>
<LI><A HREF="#hd_143">Symbolic name</A>
<LI><A HREF="#hd_156">Override Symbolic name</A>
<LI><A HREF="#hd_170">No removing</A>
<LI><A HREF="#hd_195">No symbolic name</A>
</UL>
<LI>-o
<UL>
<LI><A HREF="#hd_157">Delete revisions</A>
</UL>
<LI>-p
<UL>
<LI><A HREF="#hd_132">Print on standard output</A>
<LI><A HREF="#hd_186">Send to standard out</A>
<LI><A HREF="#hd_209">Standard output</A>
</UL>
<LI>-q
<UL>
<LI><A HREF="#hd_114">quiet</A>
<LI><A HREF="#hd_133">Quiet mode</A>
<LI><A HREF="#hd_158">Quiet mode</A>
<LI><A HREF="#hd_166">Quiet mode</A>
<LI><A HREF="#hd_171">Quiet mode</A>
<LI><A HREF="#hd_178">Quiet mode</A>
<LI><A HREF="#hd_210">Quiet Mode</A>
</UL>
<LI>-r
<UL>
<LI><A HREF="#hd_109">Check in revision</A>
<LI><A HREF="#hd_127">Check out revision</A>
<LI><A HREF="#hd_172">Revision for comparison</A>
<LI><A HREF="#hd_179">Revision for comparison</A>
<LI><A HREF="#hd_192">Only names of RCS files</A>
<LI><A HREF="#hd_199">Informations about revisions</A>
</UL>
<LI>-s
<UL>
<LI><A HREF="#hd_120">states</A>
<LI><A HREF="#hd_137">State</A>
<LI><A HREF="#hd_160">States</A>
<LI><A HREF="#hd_200">Information about Rev. with given state</A>
</UL>
<LI>-t
<UL>
<LI><A HREF="#hd_106">description</A>
<LI><A HREF="#hd_121">modification time</A>
<LI><A HREF="#hd_138">Preserve Modification time</A>
<LI><A HREF="#hd_161">Descriptive Text</A>
<LI><A HREF="#hd_162">Modification Time</A>
<LI><A HREF="#hd_173">Modification time</A>
<LI><A HREF="#hd_180">Modification time</A>
<LI><A HREF="#hd_187">Modification Time</A>
<LI><A HREF="#hd_194">Descriptive text</A>
<LI><A HREF="#hd_202">Modification Time</A>
</UL>
<LI>-t-
<UL>
<LI><A HREF="#hd_106">description</A>
</UL>
<LI>-u
<UL>
<LI><A HREF="#hd_111">unlock a revision</A>
<LI><A HREF="#hd_129">Unlock revision</A>
<LI><A HREF="#hd_151">Unlock revisions</A>
<LI><A HREF="#hd_153">Locking non-strict</A>
<LI><A HREF="#hd_168">Unlock revision</A>
</UL>
<LI>-V
<UL>
<LI><A HREF="#hd_123">version and emulation</A>
<LI><A HREF="#hd_126">Version, Emulate RCS Version</A>
<LI><A HREF="#hd_163">Version</A>
<LI><A HREF="#hd_167">Version</A>
<LI><A HREF="#hd_174">Version and Emulation</A>
<LI><A HREF="#hd_181">Version and Emulation</A>
<LI><A HREF="#hd_188">Version</A>
<LI><A HREF="#hd_203">Version and Emulation</A>
<LI><A HREF="#hd_211">Version</A>
</UL>
<LI>-w
<UL>
<LI><A HREF="#hd_122">login</A>
<LI><A HREF="#hd_139">Checked in by user</A>
<LI><A HREF="#hd_201">Revisons checked in by user</A>
</UL>
<LI>-x
<UL>
<LI><A HREF="#hd_124">suffixes</A>
<LI><A HREF="#hd_141">Suffixes</A>
<LI><A HREF="#hd_164">Suffixes</A>
<LI><A HREF="#hd_175">Suffixes</A>
<LI><A HREF="#hd_182">Suffixes</A>
<LI><A HREF="#hd_189">Suffixes</A>
<LI><A HREF="#hd_204">Suffixes</A>
</UL>
<LI>-z
<UL>
<LI><A HREF="#hd_125">time zoone</A>
<LI><A HREF="#hd_142">Time Zoone</A>
<LI><A HREF="#hd_165">Time Zone</A>
<LI><A HREF="#hd_176">Time zone</A>
<LI><A HREF="#hd_190">Time Zone</A>
<LI><A HREF="#hd_205">Time zone</A>
</UL>
<LI>About
<UL>
<LI><A HREF="#hd_2">About the manual</A>
</UL>
<LI>Access
<UL>
<LI><A HREF="#hd_145">Append Login names</A>
</UL>
<LI>Access Liste
<UL>
<LI><A HREF="#hd_146">Append Access list</A>
</UL>
<LI>ACM
<UL>
<LI><A HREF="#hd_98">Lampson, Butler W. and Schmidt, Eric E.</A>
<LI><A HREF="#hd_100">Heckel, Paul</A>
</UL>
<LI>Block moves
<UL>
<LI><A HREF="#hd_101">Tichy, Walter F.</A>
</UL>
<LI>branch
<UL>
<LI><A HREF="#hd_103">Default branch</A>
</UL>
<LI>Bugs
<UL>
<LI><A HREF="#hd_81">Bugs</A>
</UL>
<LI>change RCS
<UL>
<LI><A HREF="#hd_43">rcs -- change RCS file attributes</A>
</UL>
<LI>check in
<UL>
<LI><A HREF="#hd_25">ci -- check in RCS revisions</A>
</UL>
<LI>check out
<UL>
<LI><A HREF="#hd_34">co -- check out RCS revisions</A>
<LI><A HREF="#hd_135">Checkout by date/time</A>
</UL>
<LI>Checked in by user
<UL>
<LI><A HREF="#hd_201">Revisons checked in by user</A>
</UL>
<LI>Checkin date/time
<UL>
<LI><A HREF="#hd_197">Checkin date/time</A>
</UL>
<LI>ci
<UL>
<LI><A HREF="#hd_25">ci -- check in RCS revisions</A>
</UL>
<LI>clean up
<UL>
<LI><A HREF="#hd_55">rcsclean -- clean up working files</A>
</UL>
<LI>Clear/Caster
<UL>
<LI><A HREF="#hd_95">Brown, H.B.</A>
<LI><A HREF="#hd_96">Habermann, A. Nico</A>
</UL>
<LI>co
<UL>
<LI><A HREF="#hd_34">co -- check out RCS revisions</A>
</UL>
<LI>Code Management System
<UL>
<LI><A HREF="#hd_97">Code Management System</A>
</UL>
<LI>Command line options
<UL>
<LI><A HREF="#hd_77">Command line options of rlog</A>
</UL>
<LI>comment leader
<UL>
<LI><A HREF="#hd_148">Coment leader</A>
</UL>
<LI>compare revisions
<UL>
<LI><A HREF="#hd_63">rcsdiff -- compare RCS revisions</A>
</UL>
<LI>comparison
<UL>
<LI><A HREF="#hd_172">Revision for comparison</A>
<LI><A HREF="#hd_179">Revision for comparison</A>
</UL>
<LI>Compatibility
<UL>
<LI><A HREF="#hd_46">Compatibility</A>
</UL>
<LI>conflict
<UL>
<LI><A HREF="#hd_184">Less information</A>
</UL>
<LI>conflict styles
<UL>
<LI><A HREF="#hd_207">Specify conflict styles</A>
</UL>
<LI>Data Model
<UL>
<LI><A HREF="#hd_99">Tichy, Walter F.</A>
</UL>
<LI>date
<UL>
<LI><A HREF="#hd_118">date</A>
<LI><A HREF="#hd_135">Checkout by date/time</A>
</UL>
<LI>DEC
<UL>
<LI><A HREF="#hd_97">Code Management System</A>
</UL>
<LI>Default branch
<UL>
<LI><A HREF="#hd_196">Default branch</A>
</UL>
<LI>default form
<UL>
<LI><A HREF="#hd_131">Keyword strings</A>
</UL>
<LI>Delete revision
<UL>
<LI><A HREF="#hd_157">Delete revisions</A>
</UL>
<LI>description
<UL>
<LI><A HREF="#hd_106">description</A>
</UL>
<LI>Descriptive
<UL>
<LI><A HREF="#hd_161">Descriptive Text</A>
</UL>
<LI>Descriptive text
<UL>
<LI><A HREF="#hd_194">Descriptive text</A>
</UL>
<LI>diagnostic
<UL>
<LI><A HREF="#hd_114">quiet</A>
</UL>
<LI>diff
<UL>
<LI><A HREF="#hd_183">Output conflicts</A>
<LI><A HREF="#hd_90">Hunt, James W. and McIlroy, M. D.</A>
<LI><A HREF="#hd_100">Heckel, Paul</A>
</UL>
<LI>diff3
<UL>
<LI><A HREF="#hd_183">Output conflicts</A>
<LI><A HREF="#hd_206">Output conflicts</A>
<LI><A HREF="#hd_207">Specify conflict styles</A>
</UL>
<LI>Differences between files
<UL>
<LI><A HREF="#hd_100">Heckel, Paul</A>
</UL>
<LI>Emulate
<UL>
<LI><A HREF="#hd_126">Version, Emulate RCS Version</A>
</UL>
<LI>emulate RCS Version
<UL>
<LI><A HREF="#hd_123">version and emulation</A>
</UL>
<LI>Emulation
<UL>
<LI><A HREF="#hd_203">Version and Emulation</A>
</UL>
<LI>Emulation of RCS
<UL>
<LI><A HREF="#hd_163">Version</A>
<LI><A HREF="#hd_188">Version</A>
</UL>
<LI>Emulation of RCS Version
<UL>
<LI><A HREF="#hd_174">Version and Emulation</A>
<LI><A HREF="#hd_181">Version and Emulation</A>
</UL>
<LI>Environment
<UL>
<LI><A HREF="#hd_38">Environment</A>
<LI><A HREF="#hd_48">Environment</A>
<LI><A HREF="#hd_60">Environment</A>
<LI><A HREF="#hd_67">Environment</A>
<LI><A HREF="#hd_73">Environment</A>
<LI><A HREF="#hd_79">Environment</A>
</UL>
<LI>Environments
<UL>
<LI><A HREF="#hd_99">Tichy, Walter F.</A>
</UL>
<LI>Erase Login names
<UL>
<LI><A HREF="#hd_147">Erase Login names</A>
</UL>
<LI>Examples
<UL>
<LI><A HREF="#hd_58">Examples</A>
<LI><A HREF="#hd_66">Examples</A>
<LI><A HREF="#hd_72">Examples</A>
<LI><A HREF="#hd_78">Examples</A>
</UL>
<LI>Feldman Stuart I.
<UL>
<LI><A HREF="#hd_89">Feldman,Stuart I.</A>
</UL>
<LI>file merge
<UL>
<LI><A HREF="#hd_82">merge -- three-way file merge</A>
</UL>
<LI>File Modes
<UL>
<LI><A HREF="#hd_39">File Modes</A>
</UL>
<LI>Files
<UL>
<LI><A HREF="#hd_40">Files</A>
<LI><A HREF="#hd_47">Files</A>
<LI><A HREF="#hd_59">Files</A>
</UL>
<LI>force a deposit
<UL>
<LI><A HREF="#hd_112">force a deposit</A>
</UL>
<LI>Format
<UL>
<LI><A HREF="#hd_87">Format of RCS file</A>
</UL>
<LI>Format of RCS files.
<UL>
<LI><A HREF="#hd_87">Format of RCS file</A>
</UL>
<LI>GNU-Diff
<UL>
<LI><A HREF="#hd_90">Hunt, James W. and McIlroy, M. D.</A>
</UL>
<LI>GNU-Make
<UL>
<LI><A HREF="#hd_89">Feldman,Stuart I.</A>
</UL>
<LI>Hunt, James W. and McIlroy, M. D.
<UL>
<LI><A HREF="#hd_90">Hunt, James W. and McIlroy, M. D.</A>
</UL>
<LI>ident
<UL>
<LI><A HREF="#hd_51">ident -- identify RCS keywords</A>
</UL>
<LI>identify Keywords
<UL>
<LI><A HREF="#hd_51">ident -- identify RCS keywords</A>
</UL>
<LI>Ignore
<UL>
<LI><A HREF="#hd_191">Ignore RCS files without locks</A>
</UL>
<LI>Information
<UL>
<LI><A HREF="#hd_75">rlog -- print log messages</A>
</UL>
<LI>Information about Revisions
<UL>
<LI><A HREF="#hd_199">Informations about revisions</A>
</UL>
<LI>Information Rev. given state
<UL>
<LI><A HREF="#hd_200">Information about Rev. with given state</A>
</UL>
<LI>initial checkin
<UL>
<LI><A HREF="#hd_115">initial check in</A>
</UL>
<LI>Initialize
<UL>
<LI><A HREF="#hd_144">Initialize RCS File</A>
</UL>
<LI>Interactiv
<UL>
<LI><A HREF="#hd_159">Interactive</A>
</UL>
<LI>interactive
<UL>
<LI><A HREF="#hd_117">interactive mode</A>
<LI><A HREF="#hd_134">Interactive Mode</A>
</UL>
<LI>interactive mode
<UL>
<LI><A HREF="#hd_117">interactive mode</A>
</UL>
<LI>Introduction
<UL>
<LI><A HREF="#hd_19">Introduction to RCS commands</A>
</UL>
<LI>join
<UL>
<LI><A HREF="#hd_140">Joining revisions</A>
</UL>
<LI>just checkin
<UL>
<LI><A HREF="#hd_116">just check in</A>
</UL>
<LI>Keyword
<UL>
<LI><A HREF="#hd_37">Keyword Substitution</A>
<LI><A HREF="#hd_149">Keyword substitution</A>
<LI><A HREF="#hd_169">Keyword substitution</A>
<LI><A HREF="#hd_177">Keyword substitution</A>
<LI><A HREF="#hd_185">Keyword substitution</A>
</UL>
<LI>Keyword Author
<UL>
<LI><A HREF="#hd_37">Keyword Substitution</A>
</UL>
<LI>Keyword Date
<UL>
<LI><A HREF="#hd_37">Keyword Substitution</A>
</UL>
<LI>Keyword Header
<UL>
<LI><A HREF="#hd_37">Keyword Substitution</A>
</UL>
<LI>Keyword Id
<UL>
<LI><A HREF="#hd_37">Keyword Substitution</A>
</UL>
<LI>Keyword Locker
<UL>
<LI><A HREF="#hd_37">Keyword Substitution</A>
</UL>
<LI>Keyword Log
<UL>
<LI><A HREF="#hd_37">Keyword Substitution</A>
</UL>
<LI>Keyword Name
<UL>
<LI><A HREF="#hd_37">Keyword Substitution</A>
</UL>
<LI>Keyword RCSFile
<UL>
<LI><A HREF="#hd_37">Keyword Substitution</A>
</UL>
<LI>Keyword Revision
<UL>
<LI><A HREF="#hd_37">Keyword Substitution</A>
</UL>
<LI>Keyword Source
<UL>
<LI><A HREF="#hd_37">Keyword Substitution</A>
</UL>
<LI>Keyword State
<UL>
<LI><A HREF="#hd_37">Keyword Substitution</A>
</UL>
<LI>keyword values
<UL>
<LI><A HREF="#hd_113">keyword values</A>
</UL>
<LI>Keywords
<UL>
<LI><A HREF="#hd_51">ident -- identify RCS keywords</A>
<LI><A HREF="#hd_54">Keywords</A>
</UL>
<LI>lock
<UL>
<LI><A HREF="#hd_128">Lock revision</A>
<LI><A HREF="#hd_129">Unlock revision</A>
</UL>
<LI>lock a revision
<UL>
<LI><A HREF="#hd_110">lock a revision</A>
</UL>
<LI>Lock breaking
<UL>
<LI><A HREF="#hd_155">Do not send Mail</A>
</UL>
<LI>Lock revsion
<UL>
<LI><A HREF="#hd_150">Lock revision</A>
</UL>
<LI>Locked revisions
<UL>
<LI><A HREF="#hd_198">Locked revisions</A>
</UL>
<LI>log message
<UL>
<LI><A HREF="#hd_105">log message</A>
<LI><A HREF="#hd_154">Replace log message</A>
</UL>
<LI>log messages
<UL>
<LI><A HREF="#hd_75">rlog -- print log messages</A>
</UL>
<LI>login
<UL>
<LI><A HREF="#hd_122">login</A>
<LI><A HREF="#hd_139">Checked in by user</A>
</UL>
<LI>Login names
<UL>
<LI><A HREF="#hd_145">Append Login names</A>
</UL>
<LI>Mail
<UL>
<LI><A HREF="#hd_155">Do not send Mail</A>
</UL>
<LI>Make
<UL>
<LI><A HREF="#hd_89">Feldman,Stuart I.</A>
</UL>
<LI>merge
<UL>
<LI><A HREF="#hd_82">merge -- three-way file merge</A>
</UL>
<LI>merge revisions
<UL>
<LI><A HREF="#hd_69">rcsmerge -- merge RCS versions</A>
</UL>
<LI>Modification
<UL>
<LI><A HREF="#hd_136">Modification time</A>
<LI><A HREF="#hd_138">Preserve Modification time</A>
<LI><A HREF="#hd_173">Modification time</A>
<LI><A HREF="#hd_180">Modification time</A>
</UL>
<LI>modification time
<UL>
<LI><A HREF="#hd_119">modification time</A>
<LI><A HREF="#hd_121">modification time</A>
<LI><A HREF="#hd_162">Modification Time</A>
<LI><A HREF="#hd_187">Modification Time</A>
<LI><A HREF="#hd_202">Modification Time</A>
</UL>
<LI>name
<UL>
<LI><A HREF="#hd_143">Symbolic name</A>
<LI><A HREF="#hd_156">Override Symbolic name</A>
</UL>
<LI>Names
<UL>
<LI><A HREF="#hd_192">Only names of RCS files</A>
</UL>
<LI>no lock
<UL>
<LI><A HREF="#hd_191">Ignore RCS files without locks</A>
</UL>
<LI>no Symbolic name
<UL>
<LI><A HREF="#hd_195">No symbolic name</A>
</UL>
<LI>non-Strict Locking
<UL>
<LI><A HREF="#hd_153">Locking non-strict</A>
</UL>
<LI>output
<UL>
<LI><A HREF="#hd_132">Print on standard output</A>
<LI><A HREF="#hd_186">Send to standard out</A>
</UL>
<LI>Output conflicts
<UL>
<LI><A HREF="#hd_206">Output conflicts</A>
</UL>
<LI>override symbolic name
<UL>
<LI><A HREF="#hd_108">replace symbolic name</A>
<LI><A HREF="#hd_156">Override Symbolic name</A>
</UL>
<LI>overwriting
<UL>
<LI><A HREF="#hd_130">Force overwriting working file</A>
</UL>
<LI>pathname
<UL>
<LI><A HREF="#hd_193">Only pathname</A>
</UL>
<LI>Polymorhpic Applicative Language
<UL>
<LI><A HREF="#hd_98">Lampson, Butler W. and Schmidt, Eric E.</A>
</UL>
<LI>preserve
<UL>
<LI><A HREF="#hd_138">Preserve Modification time</A>
</UL>
<LI>print
<UL>
<LI><A HREF="#hd_132">Print on standard output</A>
</UL>
<LI>print RCS Version
<UL>
<LI><A HREF="#hd_123">version and emulation</A>
</UL>
<LI>quiet
<UL>
<LI><A HREF="#hd_114">quiet</A>
<LI><A HREF="#hd_133">Quiet mode</A>
<LI><A HREF="#hd_171">Quiet mode</A>
<LI><A HREF="#hd_178">Quiet mode</A>
</UL>
<LI>Quiet mode
<UL>
<LI><A HREF="#hd_210">Quiet Mode</A>
</UL>
<LI>Quiete mode
<UL>
<LI><A HREF="#hd_158">Quiet mode</A>
<LI><A HREF="#hd_166">Quiet mode</A>
</UL>
<LI>rcs
<UL>
<LI><A HREF="#hd_43">rcs -- change RCS file attributes</A>
<LI><A HREF="#hd_92">Tichy, Walter F.</A>
</UL>
<LI>RCS commands
<UL>
<LI><A HREF="#hd_19">Introduction to RCS commands</A>
</UL>
<LI>RCS Version
<UL>
<LI><A HREF="#hd_174">Version and Emulation</A>
<LI><A HREF="#hd_181">Version and Emulation</A>
</UL>
<LI>rcsclean
<UL>
<LI><A HREF="#hd_55">rcsclean -- clean up working files</A>
</UL>
<LI>rcsdiff
<UL>
<LI><A HREF="#hd_63">rcsdiff -- compare RCS revisions</A>
</UL>
<LI>rcsfile
<UL>
<LI><A HREF="#hd_87">Format of RCS file</A>
</UL>
<LI>rcsmerge
<UL>
<LI><A HREF="#hd_69">rcsmerge -- merge RCS versions</A>
</UL>
<LI>remove
<UL>
<LI><A HREF="#hd_170">No removing</A>
</UL>
<LI>revision
<UL>
<LI><A HREF="#hd_109">Check in revision</A>
<LI><A HREF="#hd_127">Check out revision</A>
<LI><A HREF="#hd_172">Revision for comparison</A>
<LI><A HREF="#hd_179">Revision for comparison</A>
</UL>
<LI>Revision message
<UL>
<LI><A HREF="#hd_154">Replace log message</A>
</UL>
<LI>rlog
<UL>
<LI><A HREF="#hd_75">rlog -- print log messages</A>
</UL>
<LI>SCCS
<UL>
<LI><A HREF="#hd_91">Rochkind, Marc J.</A>
<LI><A HREF="#hd_94">Glasser, Alan L.</A>
</UL>
<LI>send result to standard out.
<UL>
<LI><A HREF="#hd_186">Send to standard out</A>
</UL>
<LI>set branch
<UL>
<LI><A HREF="#hd_103">Default branch</A>
</UL>
<LI>SIGPLAN
<UL>
<LI><A HREF="#hd_93">Leblang, David B. and Chase, Robert P.</A>
</UL>
<LI>Software Quality
<UL>
<LI><A HREF="#hd_94">Glasser, Alan L.</A>
</UL>
<LI>Standard output
<UL>
<LI><A HREF="#hd_209">Standard output</A>
</UL>
<LI>State
<UL>
<LI><A HREF="#hd_137">State</A>
</UL>
<LI>states
<UL>
<LI><A HREF="#hd_120">states</A>
<LI><A HREF="#hd_160">States</A>
</UL>
<LI>Strict Locking
<UL>
<LI><A HREF="#hd_152">Strict Locking</A>
</UL>
<LI>String-To-String Correction
<UL>
<LI><A HREF="#hd_101">Tichy, Walter F.</A>
</UL>
<LI>Substitution
<UL>
<LI><A HREF="#hd_37">Keyword Substitution</A>
</UL>
<LI>suffixes
<UL>
<LI><A HREF="#hd_124">suffixes</A>
<LI><A HREF="#hd_141">Suffixes</A>
<LI><A HREF="#hd_164">Suffixes</A>
<LI><A HREF="#hd_175">Suffixes</A>
<LI><A HREF="#hd_182">Suffixes</A>
<LI><A HREF="#hd_189">Suffixes</A>
<LI><A HREF="#hd_204">Suffixes</A>
</UL>
<LI>Support
<UL>
<LI><A HREF="#hd_99">Tichy, Walter F.</A>
</UL>
<LI>Symbolic
<UL>
<LI><A HREF="#hd_143">Symbolic name</A>
<LI><A HREF="#hd_156">Override Symbolic name</A>
</UL>
<LI>symbolic name
<UL>
<LI><A HREF="#hd_107">symbolic name</A>
</UL>
<LI>Symposium
<UL>
<LI><A HREF="#hd_93">Leblang, David B. and Chase, Robert P.</A>
</UL>
<LI>tag
<UL>
<LI><A HREF="#hd_107">symbolic name</A>
<LI><A HREF="#hd_143">Symbolic name</A>
<LI><A HREF="#hd_156">Override Symbolic name</A>
</UL>
<LI>time
<UL>
<LI><A HREF="#hd_135">Checkout by date/time</A>
</UL>
<LI>Time Zone
<UL>
<LI><A HREF="#hd_165">Time Zone</A>
<LI><A HREF="#hd_176">Time zone</A>
<LI><A HREF="#hd_190">Time Zone</A>
<LI><A HREF="#hd_205">Time zone</A>
</UL>
<LI>time zoone
<UL>
<LI><A HREF="#hd_125">time zoone</A>
</UL>
<LI>time/date
<UL>
<LI><A HREF="#hd_173">Modification time</A>
<LI><A HREF="#hd_180">Modification time</A>
</UL>
<LI>Tools
<UL>
<LI><A HREF="#hd_99">Tichy, Walter F.</A>
</UL>
<LI>TZ
<UL>
<LI><A HREF="#hd_125">time zoone</A>
</UL>
<LI>unlock
<UL>
<LI><A HREF="#hd_170">No removing</A>
</UL>
<LI>unlock a revision
<UL>
<LI><A HREF="#hd_111">unlock a revision</A>
</UL>
<LI>Unlock revision
<UL>
<LI><A HREF="#hd_168">Unlock revision</A>
</UL>
<LI>Unlock revsion
<UL>
<LI><A HREF="#hd_151">Unlock revisions</A>
</UL>
<LI>Version
<UL>
<LI><A HREF="#hd_126">Version, Emulate RCS Version</A>
<LI><A HREF="#hd_163">Version</A>
<LI><A HREF="#hd_167">Version</A>
<LI><A HREF="#hd_188">Version</A>
<LI><A HREF="#hd_203">Version and Emulation</A>
<LI><A HREF="#hd_211">Version</A>
</UL>
<LI>working
<UL>
<LI><A HREF="#hd_130">Force overwriting working file</A>
</UL>
<LI>working files
<UL>
<LI><A HREF="#hd_55">rcsclean -- clean up working files</A>
</UL>
<LI>Workstation
<UL>
<LI><A HREF="#hd_93">Leblang, David B. and Chase, Robert P.</A>
</UL>
<LI>zoone
<UL>
<LI><A HREF="#hd_125">time zoone</A>
<LI><A HREF="#hd_142">Time Zoone</A>
</UL>
</UL>
</BODY>
</HTML>
