— RCS file
Revision Control System (RCS) is a software tool which lets people manage
multiple revisions of text that is revised frequently, such as source code or
program is used to create RCS files or
manipulate the contents of existing files. A set of helper tools is also
available: specific revisions of files may be checked in or out, using
; differences between revisions
viewed or merged, using
; and information
about RCS files and keyword strings displayed using
. See the respective
manual pages for more information about these utilities.
The following options are supported:
- Append the access list of
oldfile to the access list of the RCS
- Add the usernames specified in the comma-separated list
users to the access list of the RCS
- Set the default branch (see below) to
rev. If no argument is specified, the
default branch is set to the highest numbered branch.
- Set comment leader to
string. The comment leader specifies the
comment character(s) for a file. This option is useful for compatibility
with older RCS implementations only.
- Remove the usernames specified in the comma-separated list
users from the access list of the RCS
files. If users is not specified, all
users are removed from the access list.
- Interactive mode.
- Create and initialize a new RCS file. If the RCS file has
no path prefix, try to first create it in the
./RCS subdirectory or, if that fails, in the
current directory. Files created this way contain no revision.
- Specify the keyword substitution mode (see below).
- Enable strict locking on the RCS files.
- Lock revision rev on the
- Replace revision rev's log
message with msg.
- Delete one or more revisions. The specifications of the
values or revisions are as follows:
- Specific revision.
- Delete all revisions of a branch between
- Delete all revisions of a branch between
rev2 without deleting revisions
- Delete all revisions of the branch until revision
- Delete all revisions of the branch from revision
rev until the last revision of the
- Be quiet about reporting.
- Preserve the modification time of RCS files.
- Change the descriptive text. The argument
str is interpreted as the name of a file
containing the descriptive text or, if prefixed with a ‘-’,
the actual descriptive text itself. If no argument is used, the
descriptive text is taken from standard input terminated by end-of-file or
by a line containing the ‘.’ character by itself.
- Disable strict locking on the RCS files.
- Unlock revision rev on the
- Print the program's version string and exit.
- Specifies the suffixes for RCS files. Suffixes should be
separated by the ‘/’ character.
Files may be selected by revision
or, where no
revision is specified, the latest revision of the default
is used. Revisions are specified either by
using the -r
option or by appending the revision
number to any option that supports it. Branches are selected using the
A file's revision consists of two elements: release number and level number. For
example, revision 2.3 of a file denotes release 2, level 3. Levels may also be
subdivided into sublevels: this might happen, for example, if a parallel
development is forked from a lower level revision. The primary levels and the
sublevels belong to separate branches: the primary levels belong to a branch
called HEAD, while sublevels belong to branches specified by revision.
also supports the notion of
. The state is an arbitrary string of
characters used to describe a file (or a specific revision of a file). States
can be set or changed using the -s
RCS tools which support it. The state of a file/revision can be modified
without having to check in a new file/revision. The default state is
‘Exp’ (Experimental). Examples of states could be
‘Dev’, ‘Reviewed’, or ‘Stab’.
In order to make large groups of RCS files more manageable, RCS tools have the
ability to select files by their symbolic name
Thus files can be selected by their symbolic name, rather than numerical
to set symbolic names for files.
The following methods of file selection are therefore available: revision
number, state, and symbolic name. For options which take as argument
, any of these methods may be used. Some
$ co -r"myproject" foo.c
$ rcs -m1.3:update foo.c
$ ci -s"Exp" bar.c
As long as source files are edited inside a working directory, their state can
be determined using the cvs(1)
commands, but as soon as files get exported from a local working copy, it
becomes harder to identify which revisions they are.
use a mechanism known as
‘keyword substitution’ to help identify the files. Embedded
strings of the form $keyword$ and $keyword:...$ in a file are replaced with
strings of the form $keyword: value$ whenever a new revision of the file is
obtained. The possible keywords are as follows:
- The name of the user who checked in the revision.
- The date and hour (UTC) the revision was checked in.
- Standard header containing the full pathname of the RCS
file, the revision number, the date (UTC), the author and the state.
- $Id$ and $OpenBSD$
- The same content as $Header$ but without the path of the
- The log message supplied during commit, preceded by a
header containing the RCS filename, the revision number, the author, and
the date (UTC).
- Produce a date of the form month name, day number, and
year, suitable for the mdoc(7)
- The tag name used to check out the file.
- The name of the RCS file, but without a path.
- The revision number assigned to the revision.
- The full pathname of the RCS file.
- The state assigned to the revision.
Keyword substitution has its disadvantages: sometimes the literal text string
$Author$ is wanted inside a file without rcs
interpreting it as a keyword
and expanding it. The
be used to turn off keyword substitution entirely though. There is
unfortunately no way to selectively turn off keyword substitution.
Each file and working directory copy of a file have a stored default
substitution mode. Substitution modes on files are set by the
The possible substitution modes are as follows:
also avoids the conversion of line endings. This option is used to handle
- Does not substitute the keywords. Useful with the
rcsdiff(1) commands to
avoid displaying the differences between keyword substitutions.
- The default behaviour. Keywords are normally substituted
i.e. $Revision$ becomes $Revision: 1.1 $.
that the locker's name is displayed along with the version if the given
revision is currently locked. This option is normally not useful as
cvs(1) do not use file locking
- No substitutions are done. This option is often used with
import command to guarantee that files that
already contain external keywords do not get modified.
- Substitute the value of keywords instead of keywords
themselves e.g. instead of $Revision$, only insert 1.1 and not $Revision:
1.1 $. This option must be used with care, as it can only be used once. It
is often used with the cvs(1)
export command to freeze the values before
- If set, this variable should contain a list of
space-delimited options that are prepended to the argument list.
utility exits 0 on success,
and >0 if an error occurs.
One of the most common uses of rcs
is to track
changes to a document containing source code.
As an example, we'll look at a user wishing to track source changes to a file
If the RCS
directory does not exist yet, create
it as follows and invoke the check-in command:
This command creates an RCS file foo.c,v
into it as revision 1.1, and deletes
will prompt for a description
of the file to be entered. Whenever a newly created (or updated) file is
will prompt for a
log message to be entered which should summarize the changes made to the file.
That log message will be added to the RCS file along with the new revision.
command can now be used to
obtain a copy of the checked-in foo.c,v
$ co foo.c
This command checks the file out in unlocked mode. If a user wants to have
exclusive access to the file to make changes to it, it needs to be checked out
in locked mode using the -l
option of the
command. Only one concurrent
locked checkout of a revision is permitted.
Once changes have been made to the foo.c
before checking the file in, the
command can be used
to view changes between the working file and the most recently checked-in
$ rcsdiff -u foo.c
option produces a unified diff. See
for more information.
Tichy, Walter F.,
RCS -- a system for version control,
Software--Practice & Experience,
15:7, pp. 637-654,
OpenRCS is compatible with Walter Tichy's original RCS implementation.
The flags [-Mz
] have no
effect and are provided for compatibility only.
The OpenRCS project is a BSD-licensed rewrite of the original Revision Control
System. OpenRCS is written by Jean-Francois Brousseau, Joris Vink, Niall
O'Higgins, and Xavier Santolaria.
The original RCS code was written in large parts by Walter F. Tichy and Paul
For historical reasons, the RCS tools do not permit whitespace between options
and their arguments.