BSD 4_3_Reno development
authorCSRG <csrg@ucbvax.Berkeley.EDU>
Tue, 15 Aug 1989 14:23:50 +0000 (06:23 -0800)
committerCSRG <csrg@ucbvax.Berkeley.EDU>
Tue, 15 Aug 1989 14:23:50 +0000 (06:23 -0800)
Work on file usr/src/contrib/rcs/man/ci.1
Work on file usr/src/contrib/rcs/man/co.1
Work on file usr/src/contrib/rcs/man/ident.1
Work on file usr/src/contrib/rcs/man/merge.1
Work on file usr/src/contrib/rcs/man/rcs.1
Work on file usr/src/contrib/rcs/man/rcsclean.1
Work on file usr/src/contrib/rcs/man/rcsfile.5
Work on file usr/src/contrib/rcs/man/rcsfreeze.1
Work on file usr/src/contrib/rcs/man/rcsintro.1
Work on file usr/src/contrib/rcs/man/rcsmerge.1
Work on file usr/src/contrib/rcs/man/rlog.1

Synthesized-from: CSRG/cd2/4.3reno

usr/src/contrib/rcs/man/ci.1 [new file with mode: 0644]
usr/src/contrib/rcs/man/co.1 [new file with mode: 0644]
usr/src/contrib/rcs/man/ident.1 [new file with mode: 0644]
usr/src/contrib/rcs/man/merge.1 [new file with mode: 0644]
usr/src/contrib/rcs/man/rcs.1 [new file with mode: 0644]
usr/src/contrib/rcs/man/rcsclean.1 [new file with mode: 0644]
usr/src/contrib/rcs/man/rcsfile.5 [new file with mode: 0644]
usr/src/contrib/rcs/man/rcsfreeze.1 [new file with mode: 0644]
usr/src/contrib/rcs/man/rcsintro.1 [new file with mode: 0644]
usr/src/contrib/rcs/man/rcsmerge.1 [new file with mode: 0644]
usr/src/contrib/rcs/man/rlog.1 [new file with mode: 0644]

diff --git a/usr/src/contrib/rcs/man/ci.1 b/usr/src/contrib/rcs/man/ci.1
new file mode 100644 (file)
index 0000000..00df6f5
--- /dev/null
@@ -0,0 +1,231 @@
+.TH CI 1L "" "Purdue University"
+.SH NAME
+ci \- check in RCS revisions
+.SH SYNOPSIS
+.B ci
+[ options ]
+file ...
+.SH DESCRIPTION
+.I Ci
+stores new revisions into RCS files.
+Each file name ending in `,v' is taken to be an RCS file, all others
+are assumed to be working files containing new revisions.
+\fICi\fR deposits the contents of each working file
+into the corresponding RCS file.
+If only a working file is given, \fIci\fR tries to find the corresponding
+RCS file in the directory ./RCS and then in the current directory.
+For more details, see the file naming section below.
+.PP
+For \fIci\fR 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, unless locking is set to \fIstrict\fR
+(see
+.IR rcs (1L)).
+A lock held by someone else may be broken with the \fIrcs\fR command.
+.PP
+Normally, \fIci\fR checks whether the revision to be deposited is different
+from the preceding one. If it is not different, \fIci\fR
+either aborts the deposit (if
+.B \-q
+is given) or asks whether to abort
+(if
+.B \-q
+is omitted). A deposit can be forced with the
+.B \-f
+option.
+.PP
+For each revision deposited,
+.I ci
+prompts for a log message.
+The log message should summarize the change and must be terminated with
+a line containing a single `.' or a control-D.
+If several files are checked in, \fIci\fR asks whether to reuse the
+previous log message.
+If the standard input is not a terminal, \fIci\fR suppresses the prompt 
+and uses the same log message for all files.
+See also \fB\-m\fR.
+.PP
+The number of the deposited revision can be given by any of the options
+\fB\-r\fR, \fB\-f\fR, \fB\-k\fR, \fB\-l\fR, \fB\-u\fR, or \fB\-q\fR.
+.PP
+If the RCS file does not exist, \fIci\fR creates it and
+deposits the contents of the working file as the initial revision
+(default number: 1.1).
+The access list is initialized to empty.
+Instead of the log message, \fIci\fR requests descriptive text (see
+\fB\-t\fR below).
+.TP 10
+.BR \-r [\fIrev\fR] 
+assigns the revision number \fIrev\fR 
+to the checked-in revision, releases the corresponding lock, and
+deletes the working file. This is the default.
+\fIRev\fR may be symbolic, numeric, or mixed.
+
+If \fIrev\fR is a revision number, it must be higher than the latest
+one on the branch to which \fIrev\fR belongs, or must start a new branch.
+
+If \fIrev\fR 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 \fIrev\fR indicates a non-existing branch,
+that branch is created with the initial revision numbered
+.IR rev .1.
+
+.ne 8
+If \fIrev\fR is omitted, \fIci\fR 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 1.
+
+If \fIrev\fR is omitted and the caller has no lock, but he is the owner
+of the file and locking
+is not set to \fIstrict\fR, then the revision is appended to the
+default branch (normally the trunk; see the
+.B \-b
+option of
+.IR rcs (1L)).
+
+Exception: On the trunk, revisions can be appended to the end, but
+not inserted.
+.TP 10
+.BR \-f [\fIrev\fR]
+forces a deposit; the new revision is deposited even it is not different
+from the preceding one.
+.TP 10
+.BR \-k [\fIrev\fR]
+searches the working file for keyword values to determine its revision number,
+creation date, state, and author (see \fIco\fR(1)), 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 \fB\-k\fR option at these sites to 
+preserve the original number, date, author, and state.
+The extracted keyword values and the default log message may be overridden
+with the options \fB\-r\fR, \fB\-d\fR, \fB\-s\fR, \fB\-w\fR, and \fB\-m\fR.
+.TP 10
+.BR \-l [\fIrev\fR]
+works like \fB\-r\fR, except it performs an additional \fIco \fB\-l\fR 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.
+.TP 10
+.BR \-u [\fIrev\fR]
+works like \fB\-l\fR, except that the deposited revision is not locked.
+This is useful if one wants to process (e.g., compile) the revision
+immediately after checkin.
+.TP 10
+.BR \-q [\fIrev\fR] 
+quiet mode; diagnostic output is not printed.
+A revision that is not different from the preceding one is not deposited,
+unless \fB\-f\fR is given.
+.TP 10
+.BI \-d "date"
+uses \fIdate\fR for the checkin date and time.
+\fIDate\fR may be specified in free format as explained in \fIco\fR(1).
+Useful for lying about the checkin date, and for
+.B \-k
+if no date is available.
+.TP 10
+.BI \-m "msg"
+uses the string \fImsg\fR as the log message for all revisions checked in.
+.TP 10
+.BI \-n "name"
+assigns the symbolic name \fIname\fR to the number of the checked-in revision.
+\fICi\fR prints an error message if \fIname\fR is already assigned to another
+number.
+.TP 10
+.BI \-N "name"
+same as \fB\-n\fR, except that it overrides a previous assignment of \fIname\fR.
+.TP
+.BI \-s "state"
+sets the state of the checked-in revision to the identifier \fIstate\fR.
+The default is \fIExp\fR.
+.TP
+.BR \-t [\fItxtfile\fR]
+writes descriptive text into the RCS file (deletes the existing text).
+If \fItxtfile\fR is omitted, 
+\fIci\fR prompts the user for text supplied from the standard input,
+terminated with a line containing a single `.' or control-D.
+Otherwise, the descriptive text is copied from the file \fItxtfile\fR.
+During initialization, descriptive text is requested
+even if \fB\-t\fR is not given.
+The prompt is suppressed if standard input is not a terminal.
+.TP
+.BI \-w "login"
+uses \fIlogin\fR for the author field of the deposited revision.
+Useful for lying about the author, and for
+.B \-k
+if no author is available.
+.SH "FILE NAMING"
+Pairs of RCS files and working files may be specified in 3 ways (see also the
+example section of \fIco\fR(1)).
+.PP
+1) Both the RCS file and the working file are given. The RCS file name is of
+the form \fIpath1/workfile,v\fR
+and the working file name is of the form
+\fIpath2/workfile\fR, where 
+\fIpath1/\fR and
+\fIpath2/\fR are (possibly different or empty) paths and
+\fIworkfile\fR is a file name.
+.PP
+2) Only the RCS file is given. 
+Then the working file is assumed to be in the current
+directory and its name is derived from the name of the RCS file
+by removing \fIpath1/\fR and the suffix \fI,v\fR.
+.PP
+3) Only the working file is given. 
+Then \fIci\fR looks for an RCS file of the form
+\fIpath2/RCS/workfile,v\fR or \fIpath2/workfile,v\fR (in this order).
+.PP
+If the RCS file is specified without a path in 1) and 2), then \fIci\fR
+looks for the RCS file first in the directory ./RCS and then in the current
+directory.
+.SH "FILE MODES"
+An RCS file created by \fIci\fR inherits the read and execute permissions
+from the working file. If the RCS file exists already, \fIci\fR
+preserves its read and execute permissions.
+\fICi\fR always turns off all write permissions of RCS files. 
+.SH FILES
+The caller of the command
+must have read/write permission for the directories containing
+the RCS file and the working file, and read permission for the RCS file itself.
+A number of temporary files are created.
+A semaphore file is created in the directory containing the RCS file.
+\fICi\fR always creates a new RCS file and unlinks the old one.
+This strategy makes links to RCS files useless.
+.SH DIAGNOSTICS
+For each revision,
+\fIci\fR prints the RCS file, the working file, and the number
+of both the deposited and the preceding revision.
+The exit status always refers to the last file checked in,
+and is 0 if the operation was successful, 1 otherwise.
+.SH IDENTIFICATION
+.de VL
+\\$2
+..
+Author: Walter F. Tichy,
+Purdue University, West Lafayette, IN, 47907.
+.sp 0
+Revision Number:
+.VL $Revision: 1.3 $
+; Release Date:
+.VL $Date: 89/05/02 11:12:08 $
+\&.
+.sp 0
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.SH SEE ALSO
+co(1L), ident(1L), rcs(1L), rcsdiff(1L), rcsintro(1L), rcsmerge(1L), rlog(1L),
+rcsfile(5L)
+.sp 0
+Walter F. Tichy, "Design, Implementation, and Evaluation of a Revision Control
+System," in \fIProceedings of the 6th International Conference on Software
+Engineering\fR, IEEE, Tokyo, Sept. 1982.
diff --git a/usr/src/contrib/rcs/man/co.1 b/usr/src/contrib/rcs/man/co.1
new file mode 100644 (file)
index 0000000..a2d93bf
--- /dev/null
@@ -0,0 +1,305 @@
+.TH CO 1L "" "Purdue University"
+.SH NAME
+co \- check out RCS revisions
+.SH SYNOPSIS
+.B co
+[ options ]
+file ...
+.SH DESCRIPTION
+.I Co
+retrieves a revision from each RCS file and stores it into
+the corresponding working file.
+Each file name ending in `,v' is taken to be an RCS file;
+all other files are assumed to be working files.
+If only a working file is given, \fIco\fR tries to find the corresponding
+RCS file in the directory ./RCS and then in the current directory.
+For more details, see the file naming section below.
+.PP
+Revisions of an RCS file may 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. \fICo\fR with locking
+fails if the revision to be checked out is currently locked by another user.
+(A lock may be broken with the
+.IR rcs (1L)
+command.)
+\fICo\fR 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.
+\fICo\fR without locking is not subject to accesslist restrictions, and is
+not affected by the presence of locks.
+.PP
+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, \fIco\fR retrieves the latest revision
+that satisfies all of them.
+If none of the selection options
+is specified, \fIco\fR retrieves the latest revision
+on the default branch (normally the trunk, see the
+.B \-b
+option of
+.IR rcs (1L)).
+A revision or branch number may be attached
+to any of the options
+\fB\-f\fR, \fB\-l\fR, \fB\-p\fR, \fB\-q\fR, \fB\-r\fR, or \fB\-u\fR.
+The options \fB\-d\fR (date), \fB\-s\fR (state), and \fB\-w\fR (author)
+retrieve from a single branch, the \fIselected\fR branch,
+which is either specified by one of
+\fB\-f\fR,..., \fB\-u\fR, or the default branch.
+.PP
+A \fIco\fR command applied to an RCS
+file with no revisions creates a zero-length working file.
+\fICo\fR always performs keyword substitution (see below).
+.PP
+.TP 11
+.BR \-r [\fIrev\fR]
+retrieves the latest revision whose number is less than or equal to \fIrev\fR.
+If \fIrev\fR indicates a branch rather than a revision,
+the latest revision on that branch is retrieved.
+If \fIrev\fR is omitted, the latest revision on the default branch
+(see the
+.B \-b
+option of
+.IR rcs (1L))
+is retrieved.
+\fIRev\fR is composed of one or more numeric or symbolic fields
+separated by `.'. The numeric equivalent of a symbolic field
+is specified with the \fB\-n\fR option of the commands
+.IR ci (1L)
+and
+.IR rcs (1L).
+.TP 11
+.BR \-l [\fIrev\fR]
+same as \fB\-r\fR, except that it also locks the retrieved revision for
+the caller.  See option \fB\-r\fR for handling of the revision number
+.I rev .
+.TP 11
+.BR \-u [\fIrev\fR]
+same as \fB\-r\fR, except that it unlocks the retrieved revision (if it was
+locked by the caller). If \fIrev\fR is omitted, \fB\-u\fR
+retrieves the latest revision locked by the caller; if no such lock exists,
+it retrieves the latest revision on the default branch.
+.TP 11
+.BR \-f [\fIrev\fR]
+forces the overwriting of the working file;
+useful in connection with \fB\-q\fR.
+See also the section on file modes below.
+.TP 11
+.BR \-p [\fIrev\fR]
+prints the retrieved revision on the standard output rather than storing it
+in the working file.
+This option is useful when \fIco\fR
+is part of a pipe.
+.TP 11
+.BR \-q [\fIrev\fR]
+quiet mode; diagnostics are not printed.
+.TP 11
+.BI \-d "date"
+retrieves the latest revision on the selected branch whose checkin date/time is less than or equal to \fIdate\fR.
+The date and time may be given in free format and are converted to local time.
+Examples of formats for \fIdate\fR:
+.ne 5
+.nf
+
+\fI22-April-1982, 17:20-CDT,
+2:25 AM, Dec. 29, 1983,
+Tue-PDT, 1981, 4pm Jul 21\fR         \fR(free format),
+\fIFri, April 16 15:52:25 EST 1982 \fR(output of ctime).
+.fi
+
+Most fields in the date and time may be defaulted.
+\fICo\fR determines the defaults 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 current values are assumed. For all other omitted fields,
+the lowest possible values are assumed.
+For example, the date "20, 10:30" defaults to
+10:30:00 of the 20th of the current month and current year.
+The date/time must be quoted if it contains spaces.
+.TP 11
+.BI \-s "state"
+retrieves the latest revision on the selected branch whose state is set to \fIstate\fR.
+.TP 11
+.BR \-w [\fIlogin\fR]
+retrieves the latest revision on the selected branch which was checked in
+by the user with login name \fIlogin\fR. If the argument \fIlogin\fR is
+omitted, the caller's login is assumed.
+.TP 11
+.BI \-j joinlist
+generates a new revision which is the join of the revisions on \fIjoinlist\fR.
+\fIJoinlist\fR is a comma-separated list of pairs of the form
+\fIrev2:rev3\fR, where \fIrev2\fR and \fIrev3\fR are (symbolic or numeric)
+revision numbers.
+For the initial such pair, \fIrev1\fR denotes the revision selected
+by the above options \fB\-r\fR, ..., \fB\-w\fR. For all other pairs, \fIrev1\fR
+denotes the revision generated by the previous pair. (Thus, the output
+of one join becomes the input to the next.)
+
+For each pair, \fIco\fR joins revisions \fIrev1\fR and \fIrev3\fR
+with respect to \fIrev2\fR.
+This means that all changes that transform
+\fIrev2\fR into \fIrev1\fR are applied to a copy of \fIrev3\fR.
+This is particularly useful if \fIrev1\fR
+and \fIrev3\fR are the ends of two branches that have \fIrev2\fR as a common
+ancestor. If \fIrev1\fR < \fIrev2\fR < \fIrev3\fR on the same branch,
+joining generates a new revision which is like \fIrev3\fR, but with all
+changes that lead from \fIrev1\fR to \fIrev2\fR undone.
+If changes from \fIrev2\fR to \fIrev1\fR overlap with changes from
+\fIrev2\fR to \fIrev3\fR, \fIco\fR prints a warning and includes the
+overlapping sections, delimited by the lines \fI<<<<<<<\ rev1,
+=======\fR, and \fI>>>>>>>\ rev3\fR.
+
+For the initial pair, \fIrev2\fR may 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 \fB\-l\fR and \fB\-u\fR lock or unlock \fIrev1\fR.
+.SH "KEYWORD SUBSTITUTION"
+Strings of the form \fI$keyword$\fR and \fI$keyword:...$\fR embedded in
+the text are replaced
+with strings of the form \fI$keyword:\ value\ $\fR,
+where \fIkeyword\fR and \fIvalue\fR are pairs listed below.
+Keywords may be embedded in literal strings
+or comments to identify a revision.
+.PP
+Initially, the user enters strings of the form \fI$keyword$\fR.
+On checkout, \fIco\fR replaces these strings with strings of the form
+\fI$keyword:\ value\ $\fR. 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.
+.PP
+Keywords and their corresponding values:
+.TP 13
+$\&Author$
+The login name of the user who checked in the revision.
+.TP
+$\&Date$
+The date and time the revision was checked in.
+.TP
+$\&Header$
+A standard header containing the full pathname of the RCS file, the
+revision number, the date, the author, the state, and the locker (if locked).
+.TP
+$\&Id$
+Same as $\&Header$, except that the RCS file name is without a path.
+.TP
+$\&Locker$
+The login name of the user who locked the revision (empty if not locked).
+.TP
+$\&Log$
+The log message supplied during checkin, preceded by a header
+containing the RCS file name, the revision number, the author, and the date.
+Existing log messages are NOT replaced.
+Instead, the new log message is inserted after \fI$\&Log:...$\fR.
+This is useful for
+accumulating a complete change log in a source file.
+.TP
+$\&RCSfile$
+The name of the RCS file without path.
+.TP
+$\&Revision$
+The revision number assigned to the revision.
+.TP
+$\&Source$
+The full pathname of the RCS file.
+.TP
+$\&State$
+The state assigned to the revision with the
+.B \-s
+option of
+.IR rcs (1L)
+or
+.IR ci (1L).
+.TP
+.SH "FILE NAMING"
+Pairs of RCS files and working files may be specified in 3 ways (see also the
+example section).
+.PP
+1) Both the RCS file and the working file are given. The RCS file name is of
+the form \fIpath1/workfile,v\fR
+and the working file name is of the form
+\fIpath2/workfile\fR, where
+\fIpath1/\fR and
+\fIpath2/\fR are (possibly different or empty) paths and
+\fIworkfile\fR is a file name.
+.PP
+2) Only the RCS file is given. Then the working file is created in the current
+directory and its name is derived from the name of the RCS file
+by removing \fIpath1/\fR and the suffix \fI,v\fR.
+.PP
+3) Only the working file is given.
+Then \fIco\fR looks for an RCS file of the form
+\fIpath2/RCS/workfile,v\fR or \fIpath2/workfile,v\fR (in this order).
+.PP
+If the RCS file is specified without a path in 1) and 2), then \fIco\fR
+looks for the RCS file first in the directory ./RCS and then in the current
+directory.
+.SH EXAMPLES
+Suppose the current directory contains a subdirectory `RCS' with an RCS file
+`io.c,v'. Then all of the following commands retrieve the latest
+revision from `RCS/io.c,v' and store it into `io.c'.
+.nf
+.sp
+       co  io.c;    co  RCS/io.c,v;   co  io.c,v;
+       co  io.c  RCS/io.c,v;    co  io.c  io.c,v;
+       co  RCS/io.c,v  io.c;    co  io.c,v  io.c;
+.fi
+.SH "FILE MODES"
+The working file inherits the read and execute permissions from the RCS
+file. In addition, the owner write permission is turned on, unless the file
+is checked out unlocked and locking is set to \fIstrict\fR (see
+.IR rcs (1L)).
+.PP
+If a file with the name of the working file exists already and has write
+permission, \fIco\fR aborts the checkout if \fB\-q\fR is given, or asks
+whether to abort if \fB\-q\fR is not given. If the existing working file is
+not writable or \fB\-f\fR is given, the working file is deleted without asking.
+.SH FILES
+The caller of the command must have write permission in the working
+directory, read permission for the RCS file, and either read permission
+(for reading) or read/write permission (for locking) in the directory which
+contains the RCS file.
+.PP
+A number of temporary files are created.
+A semaphore file is created in the directory of the RCS file
+to prevent simultaneous update.
+.SH DIAGNOSTICS
+The RCS file name, the working file name,
+and the revision number retrieved are
+written to the diagnostic output.
+The exit status always refers to the last file checked out,
+and is 0 if the operation was successful, 1 otherwise.
+.SH IDENTIFICATION
+.de VL
+\\$2
+..
+Author: Walter F. Tichy,
+Purdue University, West Lafayette, IN, 47907.
+.sp 0
+Revision Number:
+.VL $Revision: 1.4 $
+; Release Date:
+.VL $Date: 89/05/02 11:20:22 $
+\&.
+.sp 0
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.SH SEE ALSO
+ci(1L), ident(1L), rcs(1L), rcsdiff(1L), rcsintro(1L), rcsmerge(1L), rlog(1L),
+rcsfile(5L)
+.sp 0
+Walter F. Tichy, "Design, Implementation, and Evaluation of a Revision Control
+System," in \fIProceedings of the 6th International Conference on Software
+Engineering\fR, IEEE, Tokyo, Sept. 1982.
+.SH LIMITATIONS
+The option \fB\-d\fR gets confused in some circumstances,
+and accepts no date before 1970.
+Links to the RCS and working files are not preserved.
+There is no way to suppress the expansion of keywords, except
+by writing them differently. In nroff and troff, this is done by embedding the
+null-character `\\&' into the keyword.
+.SH BUGS
+The option \fB\-j\fR does not work for
+files that contain lines with a single `.'.
diff --git a/usr/src/contrib/rcs/man/ident.1 b/usr/src/contrib/rcs/man/ident.1
new file mode 100644 (file)
index 0000000..d96370d
--- /dev/null
@@ -0,0 +1,68 @@
+.TH IDENT 1L "" "Purdue University"
+.SH NAME
+ident \- identify files
+.SH SYNOPSIS
+\fBident\fR [ \fB\-q\fR ] [ file ... ]
+.SH DESCRIPTION
+.I Ident
+searches the named files or, if no file name appears, the standard input
+for all occurrences of the pattern
+\fI$keyword:...$\fR, where \fIkeyword\fR is one of
+.nf
+
+        Author
+        Date
+        Header
+        Id
+        Locker
+        Log
+        Revision
+        RCSfile
+        Source
+        State
+
+.fi
+These patterns are normally inserted automatically by the RCS command
+.IR co (1L),
+but can also be inserted manually. The option \fB\-q\fR suppresses
+the warning given if there are no patterns in a file.
+.PP
+\fIIdent\fR works on text files as well as object files and dumps.
+For example, if the C program in file f.c contains
+.nf
+
+        char rcsid[] = "$\&Header:  Header information $";
+
+.fi
+and f.c is compiled into f.o, then the command
+.nf
+
+        ident  f.c  f.o
+
+will print
+
+        f.c:
+                $\&Header:  Header information $
+        f.o:
+                $\&Header:  Header information $
+
+.SH IDENTIFICATION
+.de VL
+\\$2
+..
+Author: Walter F. Tichy,
+Purdue University, West Lafayette, IN, 47907.
+.sp 0
+Revision Number:
+.VL $Revision: 1.2 $
+; Release Date:
+.VL $Date: 89/05/02 11:13:09 $
+\&.
+.sp 0
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.SH SEE ALSO
+ci(1L), co(1L), rcs(1L), rcsdiff(1L), rcsintro(1L), rcsmerge(1L), rlog(1L), rcsfile(5L),
+.sp 0
+Walter F. Tichy, "Design, Implementation, and Evaluation of a Revision Control
+System," in \fIProceedings of the 6th International Conference on Software
+Engineering\fR, IEEE, Tokyo, Sept. 1982.
diff --git a/usr/src/contrib/rcs/man/merge.1 b/usr/src/contrib/rcs/man/merge.1
new file mode 100644 (file)
index 0000000..3a03b37
--- /dev/null
@@ -0,0 +1,45 @@
+.TH MERGE 1L "" "Purdue University"
+.SH NAME
+merge \- three-way file merge
+.SH SYNOPSIS
+\fBmerge\fR [ \fB-p\fR ] file1 file2 file3
+.SH DESCRIPTION
+.I Merge
+incorporates all changes that lead form \fIfile2\fR to \fIfile3\fR into 
+\fIfile1\fR. The result goes to std. output if \fB-p\fR is present, into 
+\fIfile1\fR otherwise. \fIMerge\fR is useful for combining separate changes 
+to an original. Suppose \fIfile2\fR is the original, and both \fIfile1\fR 
+and \fIfile3\fR are modifications of \fIfile2\fR. Then \fImerge\fR 
+combines both changes. 
+.PP
+An overlap occurs if both \fIfile1\fR and \fIfile3\fR
+have changes in a common segment of lines.
+\fIMerge\fR prints how many overlaps occurred, and includes both alternatives
+in the result. The alternatives are delimited as follows:
+.sp
+.nf
+        <<<<<<< file1
+        lines in file1
+        =======
+        lines in file3
+        >>>>>>> file3
+.fi
+.sp
+If there are overlaps, the user should edit the result and delete one of the
+alternatives.
+.SH IDENTIFICATION
+.de VL
+\\$2
+..
+Author: Walter F. Tichy,
+Purdue University, West Lafayette, IN, 47907.
+.sp 0
+Revision Number:
+.VL $Revision: 1.2 $
+; Release Date:
+.VL $Date: 89/05/02 11:13:46 $
+\&.
+.sp 0
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.SH SEE ALSO
+diff3 (1), diff (1), rcsmerge (1L), co (1L).
diff --git a/usr/src/contrib/rcs/man/rcs.1 b/usr/src/contrib/rcs/man/rcs.1
new file mode 100644 (file)
index 0000000..3de2c98
--- /dev/null
@@ -0,0 +1,170 @@
+.TH RCS 1L "" "Purdue University"
+.SH NAME
+rcs \- change RCS file attributes
+.SH SYNOPSIS
+.B rcs
+[ options ]
+file ... 
+.SH DESCRIPTION
+.I 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 \fIrcs\fR 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 \fB\-i\fR option is present. 
+.PP
+Files ending in `,v' are RCS files, all others are working files. If
+a working file is given, \fIrcs\fR tries to find the corresponding
+RCS file first in directory ./RCS and then in the current directory,
+as explained in
+.IR co (1L).
+.TP 11
+.B \-i
+creates and initializes a new RCS file, but does not deposit any revision.
+If the RCS file has no path prefix, \fIrcs\fR tries to place it
+first into the subdirectory ./RCS, and then into the current directory.
+If the RCS file
+already exists, an error message is printed.
+.TP
+.BI \-a "logins"
+appends the login names appearing in the comma-separated list \fIlogins\fR
+to the access list of the RCS file.
+.TP
+.BI \-A "oldfile"
+appends the access list of \fIoldfile\fR to the access list of the RCS file. 
+.TP
+.BR \-e [\fIlogins\fR]
+erases the login names appearing in the comma-separated list \fIlogins\fR
+from the access list of the RCS file.
+If \fIlogins\fR is omitted, the entire access list is erased.
+.TP
+.BR \-b [\fIrev\fR]
+sets the default branch to \fIrev\fR. If \fIrev\fR is omitted, the default
+branch is reset to the (dynamically) highest branch on the trunk.
+.TP
+.BI \-c "string"
+sets the comment leader to \fIstring\fR. The comment leader
+is printed before every log message line generated by the keyword 
+$\&Log$  during checkout (see
+.IR co (1L)).
+This is useful for programming 
+languages without multi-line comments. During \fBrcs -i\fR or initial 
+\fBci\fR, the comment leader is guessed from the suffix of the working file. 
+.TP
+.BR \-l [\fIrev\fR]
+locks the revision with number \fIrev\fR.
+If a branch is given, the latest revision on that branch is locked.
+If \fIrev\fR is omitted, the latest revision on the default branch is locked.
+Locking prevents overlapping changes.
+A lock is removed with \fBci\fR or \fBrcs -u\fR (see below).
+.TP
+.BR \-u [\fIrev\fR]
+unlocks the revision with number \fIrev\fR.
+If a branch is given, the latest revision on that branch is unlocked.
+If \fIrev\fR is omitted, the latest lock held by the caller is removed.
+Normally, only the locker of a revision may 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 with a line containing a single `.' or
+control-D.
+.TP
+.B \-L
+sets locking to \fIstrict\fR. 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.
+.TP
+.B \-U
+sets locking to non-strict. Non-strict locking means that the owner of
+a file need not lock a revision for checkin. 
+This option should NOT be used for files that are shared.
+The default (\fB\-L\fR or \fB\-U\fR) is determined by your system administrator.
+.TP
+.B \-n\fIname\fR[:\fIrev\fR]
+associates the symbolic name \fIname\fR with the branch or
+revision \fIrev\fR. 
+\fIRcs\fR prints an error message if \fIname\fR is already associated with
+another number.
+If \fIrev\fR is omitted, the symbolic name is deleted.
+.TP
+.B \-N\fIname\fR[:\fIrev\fR]
+same as \fB\-n\fR, except that it overrides a previous assignment of 
+\fIname\fR.
+.TP
+.BI \-o "range"
+deletes ("outdates") the revisions given by \fIrange\fR.
+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 \fIrev1-rev2\fR means 
+revisions \fIrev1\fR to \fIrev2\fR on the same branch, 
+\fI-rev\fR means from the beginning of the branch containing
+\fIrev\fR up to and including \fIrev\fR, and \fIrev-\fR means
+from revision \fIrev\fR to the end of the branch containing \fIrev\fR.
+None of the outdated revisions may have branches or locks.
+.TP
+.B \-q
+quiet mode; diagnostics are not printed.
+.TP
+.B \-s\fIstate\fR[:\fIrev\fR]
+sets the state attribute of the revision \fIrev\fR to \fIstate\fR. 
+If \fIrev\fR is a branch number, the latest revision on that branch is
+assumed.
+If \fIrev\fR is omitted, the latest revision on the default branch is assumed.
+Any identifier is acceptable for \fIstate\fR.
+A useful set of states
+is \fIExp\fR (for experimental), \fIStab\fR (for stable), and \fIRel\fR (for
+released).
+By default,
+.IR ci (1L)
+sets the state of a revision to \fIExp\fR.
+.TP
+.BR \-t [\fItxtfile\fR]
+writes descriptive text into the RCS file (deletes the existing text).
+If \fItxtfile\fR is omitted, 
+\fIrcs\fR prompts the user for text supplied from the standard input,
+terminated with a line containing a single `.' or control-D.
+Otherwise, the descriptive text is copied from the file \fItxtfile\fR.
+If the \fB\-i\fR option is present, descriptive text is requested
+even if \fB\-t\fR is not given.
+The prompt is suppressed if the standard input is not a terminal.
+.SH DIAGNOSTICS
+The RCS file name and the revisions outdated are written to
+the diagnostic output.
+The exit status always refers to the last RCS file operated upon,
+and is 0 if the operation was successful, 1 otherwise.
+.SH FILES
+The caller of the command
+must have read/write permission for the directory containing
+the RCS file and read permission for the RCS file itself.
+.I Rcs
+creates a semaphore file in the same directory as the RCS
+file to prevent simultaneous update.
+For changes, \fIrcs\fR always creates a new file. On successful completion,
+\fIrcs\fR deletes the old one and renames the new one.
+This strategy makes links to RCS files useless.
+.SH IDENTIFICATION
+.de VL
+\\$2
+..
+Author: Walter F. Tichy,
+Purdue University, West Lafayette, IN, 47907.
+.sp 0
+Revision Number:
+.VL $Revision: 1.3 $
+; Release Date:
+.VL $Date: 89/05/02 11:14:37 $
+\&.
+.sp 0
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.SH SEE ALSO
+co(1L), ci(1L), ident(1L), rcsdiff(1L), rcsintro(1L), rcsmerge(1L), rlog(1L),
+rcsfile(5L)
+.sp 0
+Walter F. Tichy, "Design, Implementation, and Evaluation of a Revision Control
+System," in \fIProceedings of the 6th International Conference on Software
+Engineering\fR, IEEE, Tokyo, Sept. 1982.
diff --git a/usr/src/contrib/rcs/man/rcsclean.1 b/usr/src/contrib/rcs/man/rcsclean.1
new file mode 100644 (file)
index 0000000..1438b07
--- /dev/null
@@ -0,0 +1,64 @@
+.TH RCSCLEAN 1L "" "Purdue University"
+.SH NAME
+rcsclean \- clean up working files
+.SH SYNOPSIS
+\fBrcsclean\fR [ \fB-r\fIrev\fR ] [ \fB-q\fIrev\fR ] file...
+.SH DESCRIPTION
+.I Rcsclean
+removes working files that were checked out and never modified.
+For each file given, \fIrcsclean\fR
+compares the working file and a revision in the corresponding
+RCS file. If it finds no difference, it removes the working file, and,
+if the revision was locked by the caller, unlocks the revision.
+.PP
+A file name ending in ',v' is an RCS file name, otherwise a
+working file name. \fIRcsclean\fR derives the working file name from the RCS
+file name and vice versa, as explained in
+.IR co (1L).
+Pairs consisting
+of both an RCS and a working file name may also be specified.
+.PP
+\fIRev\fR specifies with which revision the working file is compared.
+If \fIrev\fR is omitted, \fIrcsclean\fR compares the working file with
+the latest revision
+on the default branch (normally the highest branch on the trunk).
+The option \fB-q\fR suppresses diagnostics.
+.PP
+\fIRcsclean\fR is useful for "clean" targets in Makefiles.
+Note that
+.IR rcsdiff (1L)
+prints out the differences.
+Also,
+.IR ci (1L)
+normally asks whether to check in a file
+if it was not changed.
+.SH EXAMPLES
+.nf
+The command
+
+       rcsclean *.c *.h
+
+.fi
+removes all working files ending in ".c" or ".h" that were not changed
+since their checkout.
+.SH DIAGNOSTICS
+The exit status is 0 if there were no differences
+during the last comparison or if the last working file did not exist,
+1 if there were differences, and 2 if there were errors.
+.SH IDENTIFICATION
+.de VL
+\\$2
+..
+Author: Walter F. Tichy,
+Purdue University, West Lafayette, IN, 47907.
+.sp 0
+Revision Number:
+.VL $Revision: 1.2 $
+; Release Date:
+.VL $Date: 89/05/02 11:15:26 $
+\&.
+.sp 0
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.SH SEE ALSO
+co(1L), ci(1L), ident(1L), rcs(1L), rcsdiff(1L), rcsintro(1L), rcsmerge(1L),
+rlog(1L), rcsfile(5L).
diff --git a/usr/src/contrib/rcs/man/rcsfile.5 b/usr/src/contrib/rcs/man/rcsfile.5
new file mode 100644 (file)
index 0000000..bcbccfe
--- /dev/null
@@ -0,0 +1,156 @@
+.TH RCSFILE 5L "" "Purdue University"
+.SH NAME
+rcsfile \- format of RCS file
+.SH DESCRIPTION
+An RCS file is an ASCII file. Its contents are described by the grammar
+below. The text is free format, i.e., spaces, tabs and new lines have
+no significance except in strings. Strings are enclosed by `@'.
+If a string contains a `@', it must be doubled.
+.PP
+The meta syntax uses the following conventions: `|' (bar) separates
+alternatives; `{' and `}' enclose optional phrases; `{' and `}*' enclose
+phrases that may be repeated zero or more times;
+`{' and '}+' enclose phrases that must appear at least once and may be
+repeated;
+`<' and `>' enclose nonterminals.
+.PP
+.ta 1.5i 2.0i 3i
+.fc ~
+.nf
+
+<rcstext>  ~~::=~~<admin> {<delta>}* <desc> {<deltatext>}*
+           
+<admin>    ~~::=~~\fBhead\fR     ~~{<num>};
+           ~~   ~~\fBbranch\fR   ~~{<num>};
+           ~~   ~~\fBaccess\fR   ~~{<id>}*;
+           ~~   ~~\fBsymbols\fR  ~~{<id> : <num>}*;  
+           ~~   ~~\fBlocks\fR    ~~{<id> : <num>}*;
+           ~~   ~~\fBcomment\fR  ~~{<string>};
+           
+<delta>    ~~::=~~<num>
+           ~~   ~~\fBdate\fR     ~~<num>;
+           ~~   ~~\fBauthor\fR   ~~<id>;
+           ~~   ~~\fBstate\fR    ~~{<id>};
+           ~~   ~~\fBbranches\fR ~~{<num>}*;
+           ~~   ~~\fBnext\fR     ~~{<num>};
+           
+<desc>     ~~::=~~\fBdesc\fR     ~~<string>
+
+<deltatext>~~::=~~<num>   
+           ~~   ~~\fBlog\fR      ~~<string>
+           ~~   ~~\fBtext\fR     ~~<string>
+
+
+<num>      ~~::=~~{<digit>{.}}+
+             
+<digit>    ~~::=~~0 | 1 | ... | 9
+             
+<id>       ~~::=~~<letter>{<idchar>}*
+
+<letter>   ~~::=~~A | B | ... | Z | a | b | ... | z
+
+<idchar>   ~~::=~~Any printing ASCII character except space,
+           ~~   ~~tab, carriage return, new line, and <special>.
+
+<special>  ~~::=~~; | : | , | @
+
+<string>   ~~::=~~@{any ASCII character, with `@' doubled}*@
+
+.fi
+.PP
+Identifiers are case sensitive. Keywords are in lower case only.
+The sets of keywords and identifiers may overlap.
+.PP
+The <delta> 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 \fBnext\fR
+field in order of decreasing numbers. The \fBhead\fR field in the
+<admin> node points to the head of that sequence (i.e., contains
+the highest pair). 
+The \fBbranch\fR 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.
+.PP
+All <delta> nodes whose numbers consist of 2n fields (n\(>=2)
+(e.g., 3.1.1.1, 2.1.2.2, etc.)
+are linked as follows. All nodes whose first (2n)-1 number fields are identical
+are linked through the \fBnext\fR field in order of increasing numbers.
+For each such sequence, 
+the <delta> node whose number is identical to the first 
+2(n-1) number fields of the deltas on that sequence is called the branchpoint.
+The \fBbranches\fR 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.
+.sp 1
+.ne 38
+Example:
+.eo
+.nf
+.vs 12pts
+.cs 1 20
+.if t .in +0.5i
+                           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  /             
+                          \     /              
+                           \   /               
+                            \ /                
+                                               
+
+.if t .in -0.5i
+.cs 1
+.ec
+.ce
+Fig. 1: A revision tree
+.fi
+.PP
+.SH IDENTIFICATION
+.de VL
+\\$2
+..
+Author: Walter F. Tichy,
+Purdue University, West Lafayette, IN, 47907.
+.sp 0
+Revision Number:
+.VL $Revision: 1.2 $
+; Release Date:
+.VL $Date: 89/05/02 11:16:56 $
+\&.
+.sp 0
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.SH SEE ALSO
+ci(1L), co(1L), ident(1L), rcs(1L), rcsdiff(1L), rcsmerge(1L), rlog(1L),
+.br
+Walter F. Tichy, "Design, Implementation, and Evaluation of a Revision Control
+System," in \fIProceedings of the 6th International Conference on Software
+Engineering\fR, IEEE, Tokyo, Sept. 1982.
diff --git a/usr/src/contrib/rcs/man/rcsfreeze.1 b/usr/src/contrib/rcs/man/rcsfreeze.1
new file mode 100644 (file)
index 0000000..98a6ae2
--- /dev/null
@@ -0,0 +1,50 @@
+.TH RCSFREEZE 1L "" "Purdue University"
+.SH NAME
+rcsfreeze \- freeze a configuration of sources checked in under RCS
+.SH SYNOPSIS
+.B rcsfreeze
+[symbolic revision name]
+.SH DESCRIPTION
+The
+.I rcsfreeze
+command has the purpose of assigning a symbolic revision
+number to a set of RCS files, which form a valid configuration.
+.PP
+The idea is to run
+.I rcsfreeze
+each time a new version is checked
+in. A unique symbolic revision number (\c
+.BI C_ number,
+where
+.I number
+is increased each time rcsfreeze is run) is then assigned to the most
+recent revision of each RCS file of the main trunk.
+.PP
+If the command is invoked with an argument, then this
+argument is used as the symbolic name to freeze a configuration.
+The unique identifier is still generated
+and is listed in the log file but it will not appear as
+part of the symbolic revision name in the actual RCS files.
+.PP
+A log message is requested from the user which is saved for future
+references.
+.PP
+The shell script works only on all RCS files at one time.
+It is important that all changed files are checked in (there are
+no precautions against any error in this respect). Run
+.IR rcsclean (1L)
+first and see whether any sources remain in the current directory.
+.SH FILES
+.TP 2.5i
+[RCS/]rcsfreeze.version
+for the version number
+.TP
+[RCS/]rscfreeze.log
+for the log messages, most recent log message first.
+.SH AUTHOR
+Stephan v. Bechtolsheim
+.SH "SEE ALSO"
+rcs(1L), rlog(1L), rcsclean(1L)
+.SH BUGS
+The program does not check whether there are any sources checked out
+and modified.
diff --git a/usr/src/contrib/rcs/man/rcsintro.1 b/usr/src/contrib/rcs/man/rcsintro.1
new file mode 100644 (file)
index 0000000..68aa9a0
--- /dev/null
@@ -0,0 +1,241 @@
+.TH RCSINTRO 1L "May 11, 1983" "Purdue University"
+.SH NAME
+rcsintro - introduction to RCS commands
+.SH DESCRIPTION
+The Revision Control System (RCS) manages multiple revisions of text 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, form letters, etc.
+.PP
+The basic user interface is extremely simple. The novice only needs
+to learn two commands:
+.IR ci (1L)
+and
+.IR co (1L).
+\fICi\fR, short for "check in", deposits the contents of a
+text file into an archival file called an RCS file. An RCS file
+contains all revisions of a particular text file.
+\fICo\fR, short for "check out", retrieves revisions from an RCS file.
+.PP
+.B "Functions of RCS"
+.PP
+.IP \(bu
+Storage and retrieval of multiple revisions of text. RCS saves 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.
+.IP \(bu
+Maintenance of a complete history of changes. RCS logs all 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.
+.IP \(bu
+Resolution of access conflicts. When two or more programmers wish to
+modify the same revision, RCS alerts the programmers and prevents one
+modification from corrupting the other.
+.IP \(bu
+Maintenance of a tree of Revisions. RCS can maintain separate lines of development
+for each module. It stores a tree structure that represents the
+ancestral relationships among revisions.
+.IP \(bu
+Merging of revisions and resolution of conflicts.
+Two separate 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.
+.IP \(bu
+Release and configuration control. Revisions can be assigned symbolic names
+and marked as released, stable, experimental, etc.
+With these facilities, configurations of modules can be
+described simply and directly.
+.IP \(bu
+Automatic identification of each revision with name, 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.
+.IP \(bu
+Minimization of secondary storage. RCS needs little extra space for
+the revisions (only the differences). If intermediate revisions are
+deleted, the corresponding deltas are compressed accordingly.
+.sp
+.PP
+.B "Getting Started with RCS"
+.PP
+Suppose you have a file f.c that you wish to put under control of RCS. 
+Invoke the check-in command
+.PP
+.ti 1.5i
+.B "ci  f.c 
+.PP
+This command creates the RCS file f.c,v, stores f.c into it as revision 1.1, and
+deletes f.c.  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.
+.PP
+Files ending in ,v are called RCS files (`v' stands for `versions'),
+the others are called working files.
+To get back the working file f.c in the previous example, use the check-out
+command
+.PP
+.ti 1.5i
+.B "co  f.c
+.PP
+This command extracts the latest revision from f.c,v and writes
+it into f.c. You can now edit f.c and check it back in by invoking
+.PP
+.ti 1.5i
+.B "ci  f.c
+.PP
+\fICi\fR increments the revision number properly. 
+If \fIci\fR complains with the message
+.PP
+               ci error: no lock set by <your login>
+.PP
+then your system administrator has decided to create all RCS files
+with the locking attribute set to `strict'. In this case, you should
+have locked the revision during the previous check-out. Your last check-out
+should have been
+.PP
+.ti 1.5i
+.B "co  \-l  f.c
+.PP
+Of course, it is too late now to do the check-out with locking, because you
+probably modified f.c already, and a second check-out would
+overwrite your modifications. Instead, invoke
+.PP
+.ti 1.5i
+.B "rcs  \-l  f.c
+.PP
+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.
+.PP
+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 CHECK-IN by anybody but the locker.
+.PP
+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
+.PP
+.ti 1.5i
+.BR "rcs  \-U  f.c" "     and     " "rcs  \-L  f.c"
+.PP
+If you don't want to clutter your working directory with RCS files, create 
+a subdirectory called RCS in your working 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 3 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).
+.PP
+To avoid the deletion of the working file during check-in (in case you want to
+continue editing), invoke
+.PP
+.ti 1.5i
+.BR "ci  \-l  f.c" "     or     " "ci  \-u  f.c"
+.PP
+These commands check in f.c 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 locking is strict, the second one if not strict.
+Both update the identification markers in your working file (see below).
+.PP
+You can give \fIci\fR 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
+.PP
+.ti 1.5i
+.BR "ci  \-r2  f.c" "     or     " "ci  \-r2.1  f.c"
+.PP
+assigns the number 2.1 to the new revision.
+From then on, \fIci\fR will number the subsequent revisions
+with 2.2, 2.3, etc. The corresponding \fIco\fR commands
+.PP
+.ti 1.5i
+.BR "co  \-r2  f.c" "     and     " "co  \-r2.1  f.c"
+.PP
+retrieve the latest revision numbered 2.x and the revision 2.1,
+respectively. \fICo\fR without a revision number selects
+the latest revision on the "trunk", i.e., the highest
+revision with a number consisting of 2 fields. Numbers with more than 2
+fields are needed for branches.
+For example, to start a branch at revision 1.3, invoke
+.PP
+.ti 1.5i
+.B "ci  \-r1.3.1  f.c
+.PP
+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 \fIrcsfile\fR(5L).
+.sp
+.PP
+.B "Automatic Identification"
+.PP
+RCS can put special strings for identification into your source and object
+code. To obtain such identification, place the marker
+.PP
+.ti 1.5i
+$\&Header$
+.PP
+into your text, for instance inside a comment.
+RCS will replace this marker with a string of the form
+.PP
+.ti 1.5i
+$\&Header:  filename  revision_number  date  time  author  state $
+.PP
+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:
+.PP
+.ti 1.5i
+static char rcsid[] = "$\&Header$";
+.PP
+The command \fIident\fR extracts such markers from any file, even object code
+and dumps.
+Thus, \fIident\fR lets you find out
+which revisions of which modules were used in a given program. 
+.PP
+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 \fIco\fR(1L) for
+details.
+.SH IDENTIFICATION
+.de VL
+\\$2
+..
+Author: Walter F. Tichy,
+Purdue University, West Lafayette, IN, 47907.
+.br
+Revision Number:
+.VL $Revision: 1.2 $
+; Release Date:
+.VL $Date: 89/05/02 11:17:54 $
+\&.
+.br
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.SH SEE ALSO
+ci(1L), co(1L), ident(1L), merge(1L), rcs(1L), rcsdiff(1L), rcsmerge(1L), rlog(1L),
+rcsfile(5L),
+.br
+Walter F. Tichy, "Design, Implementation, and Evaluation of a Revision Control
+System," in \fIProceedings of the 6th International Conference on Software
+Engineering\fR, IEEE, Tokyo, Sept. 1982.
diff --git a/usr/src/contrib/rcs/man/rcsmerge.1 b/usr/src/contrib/rcs/man/rcsmerge.1
new file mode 100644 (file)
index 0000000..56ee70f
--- /dev/null
@@ -0,0 +1,75 @@
+.TH RCSMERGE 1L "" "Purdue University"
+.SH NAME
+rcsmerge \- merge RCS revisions
+.SH SYNOPSIS
+\fBrcsmerge\fR \fB\-r\fIrev1\fR [ \fB\-r\fIrev2\fR ] [ \fB\-p\fR ] file
+.SH DESCRIPTION
+.I Rcsmerge
+incorporates the changes between \fIrev1\fR and \fIrev2\fR of an
+RCS file into the corresponding working file. If \fB\-p\fR is given, the result
+is printed on the standard output, otherwise the result overwrites the
+working file.
+.PP
+A file name ending in ',v' is an RCS file name, otherwise a
+working file name. \fIMerge\fR derives the working file name from the RCS
+file name and vice versa, as explained in
+.IR co (1L).
+A pair consisting
+of both an RCS and a working file name may also be specified.
+.PP
+\fIRev1\fR may not be omitted. If \fIrev2\fR is omitted, the latest
+revision on the default branch (normally the highest branch on the trunk)
+is assumed.
+Both \fIrev1\fR and \fIrev2\fR may be given numerically or symbolically.
+.PP
+\fIRcsmerge\fR prints a warning if there are overlaps, and delimits
+the overlapping regions as explained in \fIco \-j\fR.
+The command is useful for incorporating changes into a checked-out revision.
+.SH EXAMPLES
+Suppose you have released revision 2.8 of f.c. Assume
+furthermore that you just completed revision 3.4, when you receive
+updates to release 2.8 from someone else.
+To combine the updates to 2.8 and your changes between 2.8 and 3.4,
+put the updates to 2.8 into file f.c and execute
+.sp
+.B "        rcsmerge  \-p  \-r2.8  \-r3.4  f.c  >f.merged.c
+.sp
+Then examine f.merged.c.
+Alternatively, if you want to save the updates to 2.8 in the RCS file,
+check them in as revision 2.8.1.1 and execute \fIco \-j\fR:
+.sp
+.B "        ci  \-r2.8.1.1  f.c
+.br
+.B "        co  \-r3.4  \-j2.8:2.8.1.1  f.c
+.sp
+As another example, the following command undoes the changes
+between revision 2.4 and 2.8 in your currently checked out revision
+in f.c.
+.sp
+.B "        rcsmerge  \-r2.8  \-r2.4  f.c
+.sp
+Note the order of the arguments, and that f.c will be
+overwritten.
+.SH IDENTIFICATION
+.de VL
+\\$2
+..
+Author: Walter F. Tichy,
+Purdue University, West Lafayette, IN, 47907.
+.sp 0
+Revision Number:
+.VL $Revision: 1.2 $
+; Release Date:
+.VL $Date: 89/05/02 11:18:34 $
+\&.
+.sp 0
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.SH SEE ALSO
+ci(1L), co(1L), merge(1L), ident(1L), rcs(1L), rcsdiff(1L), rlog(1L), rcsfile(5L),
+.br
+Walter F. Tichy, "Design, Implementation, and Evaluation of a Revision Control
+System," in \fIProceedings of the 6th International Conference on Software
+Engineering\fR, IEEE, Tokyo, Sept. 1982.
+.SH BUGS
+\fIRcsmerge\fR does not work on
+files that contain lines with a single `.'.
diff --git a/usr/src/contrib/rcs/man/rlog.1 b/usr/src/contrib/rcs/man/rlog.1
new file mode 100644 (file)
index 0000000..7a8b01c
--- /dev/null
@@ -0,0 +1,133 @@
+.TH RLOG 1L "" "Purdue University"
+.SH NAME
+rlog \- print log messages and other information about RCS files
+.SH SYNOPSIS
+.B rlog
+[ options ]
+file ...
+.SH DESCRIPTION
+.I Rlog
+prints information about RCS files.
+Files ending in `,v' are RCS files, all others are working files. If
+a working file is given, \fIrlog\fR tries to find the corresponding
+RCS file first in directory ./RCS and then in the current directory,
+as explained in
+.IR co (1L).
+.PP
+\fIRlog\fR prints the following information for each
+RCS file: RCS file name, working file name, 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,
+\fIrlog\fR 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.
+Without options, \fIrlog\fR prints complete information.
+The options below restrict this output.
+.TP 10
+.B \-L
+ignores RCS files that have no locks set; convenient in combination with
+\fB\-R\fR, \fB\-h\fR, or \fB\-l\fR.
+.TP 10
+.B \-R
+only prints the name of the RCS file; convenient for translating a
+working file name into an RCS file name.
+.TP 10
+.B \-h
+prints only RCS file name, working file name, head, 
+default branch, access list, locks,
+symbolic names, and suffix.
+.TP 10
+.B \-t
+prints the same as \fB\-h\fR, plus the descriptive text.
+.TP 10
+.B \-b
+prints information about the revisions on the default branch (normally
+the highest branch on the trunk).
+.TP 10
+.BI \-d "dates"
+prints information about revisions with a checkin date/time in the ranges given by
+the semicolon-separated list of \fIdates\fR.
+A range of the form \fId1<d2\fR or \fId2>d1\fR
+selects the revisions that were deposited between
+\fId1\fR and \fId2\fR, (inclusive).
+A range of the form \fI<d\fR or \fId>\fR selects
+all revisions dated
+\fId\fR or earlier.
+A range of the form \fId<\fR or \fI>d\fR selects
+all revisions dated \fId\fR or later.
+A range of the form \fId\fR selects the single, latest revision dated \fId\fR or
+earlier.
+The date/time strings \fId, d1, \fRand \fId2\fR
+are in the free format explained in
+.IR co (1L). 
+Quoting is normally necessary, especially for \fI<\fR and \fI>\fR. Note that the separator is
+a semicolon.
+.TP 10
+.B \-l\fR[\fIlockers\fR]
+prints information about locked revisions.
+If the comma-separated list \fIlockers\fR of login names is given,
+only the revisions locked by the given login names are printed.
+If the list is omitted, all locked revisions are printed.
+.TP 10
+.BI \-r "revisions"
+prints information about revisions given in the comma-separated list
+\fIrevisions\fR of revisions and ranges. A range \fIrev1-rev2\fR means revisions
+\fIrev1\fR to \fIrev2\fR on the same branch, \fI-rev\fR means revisions
+from the beginning of the branch up to and including \fIrev\fR,
+and \fIrev-\fR means revisions starting with \fIrev\fR to the end of the
+branch containing \fIrev\fR. 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.
+.TP 10
+.BI \-s "states"
+prints information about revisions whose state attributes match one of the
+states given in the comma-separated list \fIstates\fR.
+.TP 10
+.B \-w\fR[\fIlogins\fR]
+prints information about revisions checked in by users with 
+login names appearing in the comma-separated list \fIlogins\fR.
+If \fIlogins\fR is omitted, the user's login is assumed.
+.PP
+\fIRlog\fR prints the intersection of the revisions selected with
+the options \fB\-d\fR, \fB\-l\fR, \fB\-s\fR, \fB\-w\fR, intersected
+with the union of the revisions selected by \fB\-b\fR and \fB\-r\fR.
+.SH EXAMPLES
+.nf
+.sp
+        rlog  \-L  \-R  RCS/*,v
+        rlog  \-L  \-h  RCS/*,v
+        rlog  \-L  \-l  RCS/*,v
+        rlog  RCS/*,v
+.sp
+.fi
+The first command prints the names of all RCS files in the subdirectory `RCS'
+which 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.
+.SH DIAGNOSTICS
+The exit status always refers to the last RCS file operated upon,
+and is 0 if the operation was successful, 1 otherwise.
+.SH IDENTIFICATION
+.de VL
+\\$2
+..
+Author: Walter F. Tichy,
+Purdue University, West Lafayette, IN, 47907.
+.sp 0
+Revision Number:
+.VL $Revision: 1.3 $
+; Release Date:
+.VL $Date: 89/05/02 11:19:20 $
+\&.
+.sp 0
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.SH SEE ALSO
+ci(1L), co(1L), ident(1L), rcs(1L), rcsdiff(1L), rcsintro(1L), rcsmerge(1L),
+rcsfile(5L)
+.br
+Walter F. Tichy, "Design, Implementation, and Evaluation of a Revision Control
+System," in \fIProceedings of the 6th International Conference on Software
+Engineering\fR, IEEE, Tokyo, Sept. 1982.