BSD 4_4_Lite2 development
authorCSRG <csrg@ucbvax.Berkeley.EDU>
Wed, 30 Dec 1992 10:03:53 +0000 (02:03 -0800)
committerCSRG <csrg@ucbvax.Berkeley.EDU>
Wed, 30 Dec 1992 10:03:53 +0000 (02:03 -0800)
Work on file usr/src/contrib/rcs-V5.6/man/co.1
Work on file usr/src/contrib/rcs-V5.6/man/ident.1
Work on file usr/src/contrib/rcs-V5.6/man/merge.1
Work on file usr/src/contrib/rcs-V5.6/man/rcsfile.5
Work on file usr/src/contrib/rcs-V5.6/man/rcsdiff.1
Work on file usr/src/contrib/rcs-V5.6/man/rcs.1
Work on file usr/src/contrib/rcs-V5.6/man/rcsfreeze.1
Work on file usr/src/contrib/rcs-V5.6/man/rcsclean.1
Work on file usr/src/contrib/rcs-V5.6/man/rcsintro.1
Work on file usr/src/contrib/rcs-V5.6/man/rcsmerge.1
Work on file usr/src/contrib/rcs-V5.6/man/rlog.1
Work on file usr/src/contrib/rcs-V5.6/COPYING
Work on file usr/src/contrib/rcs-V5.6/README
Work on file usr/src/contrib/rcs-V5.6/rcs_func.ms
Work on file usr/src/contrib/rcs-V5.6/Makefile

Synthesized-from: CSRG/cd3/4.4BSD-Lite2

15 files changed:
usr/src/contrib/rcs-V5.6/COPYING [new file with mode: 0644]
usr/src/contrib/rcs-V5.6/Makefile [new file with mode: 0644]
usr/src/contrib/rcs-V5.6/README [new file with mode: 0644]
usr/src/contrib/rcs-V5.6/man/co.1 [new file with mode: 0644]
usr/src/contrib/rcs-V5.6/man/ident.1 [new file with mode: 0644]
usr/src/contrib/rcs-V5.6/man/merge.1 [new file with mode: 0644]
usr/src/contrib/rcs-V5.6/man/rcs.1 [new file with mode: 0644]
usr/src/contrib/rcs-V5.6/man/rcsclean.1 [new file with mode: 0644]
usr/src/contrib/rcs-V5.6/man/rcsdiff.1 [new file with mode: 0644]
usr/src/contrib/rcs-V5.6/man/rcsfile.5 [new file with mode: 0644]
usr/src/contrib/rcs-V5.6/man/rcsfreeze.1 [new file with mode: 0644]
usr/src/contrib/rcs-V5.6/man/rcsintro.1 [new file with mode: 0644]
usr/src/contrib/rcs-V5.6/man/rcsmerge.1 [new file with mode: 0644]
usr/src/contrib/rcs-V5.6/man/rlog.1 [new file with mode: 0644]
usr/src/contrib/rcs-V5.6/rcs_func.ms [new file with mode: 0644]

diff --git a/usr/src/contrib/rcs-V5.6/COPYING b/usr/src/contrib/rcs-V5.6/COPYING
new file mode 100644 (file)
index 0000000..a43ea21
--- /dev/null
@@ -0,0 +1,339 @@
+                   GNU GENERAL PUBLIC LICENSE
+                      Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+                          675 Mass Ave, Cambridge, MA 02139, USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+                           Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+\f
+                   GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+  2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+    a) You must cause the modified files to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    b) You must cause any work that you distribute or publish, that in
+    whole or in part contains or is derived from the Program or any
+    part thereof, to be licensed as a whole at no charge to all third
+    parties under the terms of this License.
+
+    c) If the modified program normally reads commands interactively
+    when run, you must cause it, when started running for such
+    interactive use in the most ordinary way, to print or display an
+    announcement including an appropriate copyright notice and a
+    notice that there is no warranty (or else, saying that you provide
+    a warranty) and that users may redistribute the program under
+    these conditions, and telling the user how to view a copy of this
+    License.  (Exception: if the Program itself is interactive but
+    does not normally print such an announcement, your work based on
+    the Program is not required to print an announcement.)
+\f
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+    a) Accompany it with the complete corresponding machine-readable
+    source code, which must be distributed under the terms of Sections
+    1 and 2 above on a medium customarily used for software interchange; or,
+
+    b) Accompany it with a written offer, valid for at least three
+    years, to give any third party, for a charge no more than your
+    cost of physically performing source distribution, a complete
+    machine-readable copy of the corresponding source code, to be
+    distributed under the terms of Sections 1 and 2 above on a medium
+    customarily used for software interchange; or,
+
+    c) Accompany it with the information you received as to the offer
+    to distribute corresponding source code.  (This alternative is
+    allowed only for noncommercial distribution and only if you
+    received the program in object code or executable form with such
+    an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it.  For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable.  However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+\f
+  4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License.  Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+  5. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Program or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+  6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+  7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+\f
+  8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded.  In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+  9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation.  If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+  10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission.  For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this.  Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+                           NO WARRANTY
+
+  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+                    END OF TERMS AND CONDITIONS
+\f
+       Appendix: How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) 19yy  <name of author>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+    Gnomovision version 69, Copyright (C) 19yy name of author
+    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  Here is a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+  `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+  <signature of Ty Coon>, 1 April 1989
+  Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs.  If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library.  If this is what you want to do, use the GNU Library General
+Public License instead of this License.
diff --git a/usr/src/contrib/rcs-V5.6/Makefile b/usr/src/contrib/rcs-V5.6/Makefile
new file mode 100644 (file)
index 0000000..fd0724a
--- /dev/null
@@ -0,0 +1,20 @@
+SUBDIR=        src man
+DESTDIR=
+
+all: ${SUBDIR}
+
+${SUBDIR}: FRC
+       cd $@; make ${MFLAGS} DESTDIR=${DESTDIR}
+
+install:
+       for i in ${SUBDIR}; do \
+               (cd $$i; make ${MFLAGS} DESTDIR=${DESTDIR} install); \
+       done
+
+clean:
+       for i in ${SUBDIR}; do \
+               (cd $$i; make ${MFLAGS} DESTDIR=${DESTDIR} clean); \
+       done
+
+FRC:
+
diff --git a/usr/src/contrib/rcs-V5.6/README b/usr/src/contrib/rcs-V5.6/README
new file mode 100644 (file)
index 0000000..c320e09
--- /dev/null
@@ -0,0 +1,407 @@
+This directory contains complete sources for RCS version 5.6.
+
+RCS, the Revision Control System, manages multiple revisions of files.
+RCS can store, retrieve, log, identify, and merge revisions.
+It is useful for files that are revised frequently,
+e.g. programs, documentation, graphics, and papers.
+
+/* Copyright (C) 1982, 1988, 1989 Walter Tichy
+   Copyright 1990, 1991 by Paul Eggert
+   Distributed under license by the Free Software Foundation, Inc.
+
+This file is part of RCS.
+
+RCS is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+RCS is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with RCS; see the file COPYING.  If not, write to
+the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+
+Report problems and direct all questions to:
+
+    rcs-bugs@cs.purdue.edu
+
+*/
+
+$Id: README,v 5.16 1991/11/03 01:09:19 eggert Exp $
+
+
+Installation notes:
+
+  RCS requires a diff that supports the -n option.
+  Get GNU diff (version 1.15 or later) if your diff lacks -n.
+
+  RCS works best with a diff that supports -a and -L,
+  and a diff3 that supports -E and -m.
+  GNU diff supports these options.
+
+  Sources for RCS are in the src directory.
+  Read the directions in src/README to build RCS on your system.
+
+  Manual entries reside in man.
+
+  Troff source for the paper `RCS--A System for Version Control', which
+  appeared in _Software--Practice & Experience_, is in rcs.ms.
+
+  If you don't have troff, you can get GNU groff to format the documentation.
+
+
+RCS compatibility notes:
+
+  RCS version 5 reads RCS files written by any RCS version released since 1982.
+  It also writes RCS files that these older versions of RCS can read,
+  unless you use one of the following new features:
+
+       checkin times after 1999/12/31 23:59:59 GMT
+       checking in non-text files
+       non-Ascii symbolic names
+       rcs -bX, where X is nonempty
+       rcs -kX, where X is not `kv'
+       RCS files that exceed hardcoded limits in older RCS versions
+
+  A working file written by RCS 5.5 or later contains four-digit years in its
+  keyword strings.  If you check out a working file with RCS 5.5 or later,
+  an older RCS version's `ci -k' may insist on two-digit years.
+  Fix this with `co -V4', or by editing the working file.
+
+
+Features new to RCS version 5.6 include:
+
+  Security holes have been plugged; setgid use is no longer supported.
+
+  co can retrieve old revisions much more efficiently.
+  To generate the Nth youngest revision on the trunk,
+  the old method used up to N passes through copies of the working file;
+  the new method uses a piece table to generate the working file in one pass.
+
+  When ci finds no changes in the working file,
+  it automatically reverts to the previous revision unless -f is given.
+
+  RCS follows symbolic links to RCS files instead of breaking them,
+  and warns when it breaks hard links to RCS files.
+
+  `$' stands for the revision number taken from working file keyword strings.
+  E.g. if F contains an Id keyword string,
+  `rcsdiff -r$ F' compares F to its checked-in revision, and
+  `rcs -nL:$ F' gives the symbolic name L to F's revision.
+
+  co and ci's new -M option sets the modification time
+  of the working file to be that of the revision.
+  Without -M, ci now tries to avoid changing the working file's
+  modification time if its contents are unchanged.
+
+  rcs's new -m option changes the log message of an old revision.
+
+  RCS is portable to hosts that do not permit `,' in filenames.
+  (`,' is not part of the Posix portable filename character set.)
+  A new -x option specifies extensions other than `,v' for RCS files.
+  The Unix default is `-x,v/', so that the working file `w' corresponds
+  to the first file in the list `RCS/w,v', `w,v', `RCS/w' that works.
+  The non-Unix default is `-x', so that only `RCS/w' is tried.
+  Eventually, the Unix default should change to `-x/,v'
+  to encourage interoperability among all Posix hosts.
+
+  A new RCSINIT environment variable specifies defaults for options like -x.
+
+  The separator for revision ranges has been changed from `-' to `:', because
+  the range `A-B' is ambiguous if `A', `B' and `A-B' are all symbolic names.
+  E.g. the old `rlog -r1.5-1.7' is now `rlog -r1.5:1.7'; ditto for `rcs -o'.
+  For a while RCS will still support (but warn about) the old `-' separator.
+
+  RCS manipulates its lock files using a method that is more reliable under NFS.
+
+  Experimental support for MS-DOS and OS/2 is available as part of a separate
+  software distribution.
+
+
+Features new to RCS version 5 include:
+
+  RCS can check in arbitrary files, not just text files, if diff -a works.
+  RCS can merge lines containing just a single `.' if diff3 -m works.
+  GNU diff supports the -a and -m options.
+
+  RCS can now be used as a setuid program.
+  See ci(1) for how users can employ setuid copies of ci, co, and rcsclean.
+  Setuid privileges yield extra security if the effective user owns RCS files
+  and directories, and if only the effective user can write RCS directories.
+  RCS uses the real user for all accesses other than writing RCS directories.
+  As described in ci(1), there are three levels of setuid support.
+
+    1.  Setuid works fully if the seteuid() system call lets any
+    process switch back and forth between real and effective users,
+    as specified in Posix 1003.1a Draft 5.
+
+    2.  On hosts with saved setuids (a Posix 1003.1-1990 option) and without
+    a modern seteuid(), setuid works unless the real or effective user is root.
+
+    3.  On hosts that lack both modern seteuid() and saved setuids,
+    setuid does not work, and RCS uses the effective user for all accesses;
+    formerly it was inconsistent.
+
+  New options to co, rcsdiff, and rcsmerge give more flexibility to keyword
+  substitution.
+
+    -kkv substitutes the default `$Keyword: value $' for keyword strings.
+    However, a locker's name is inserted only as a file is being locked,
+    i.e. by `ci -l' and `co -l'.  This is normally the default.
+
+    -kkvl acts like -kkv, except that a locker's name is always inserted
+    if the given revision is currently locked.  This was the default in
+    version 4.  It is now the default only with when using rcsdiff to
+    compare a revision to a working file whose mode is that of a file
+    checked out for changes.
+
+    -kk substitutes just `$Keyword$', which helps to ignore keyword values
+    when comparing revisions.
+
+    -ko retrieves the old revision's keyword string, thus bypassing keyword
+    substitution.
+
+    -kv retrieves just `value'.  This can ease the use of keyword values, but
+    it is dangerous because it causes RCS to lose track of where the keywords
+    are, so for safety the owner write permission of the working file is
+    turned off when -kv is used; to edit the file later, check it out again
+    without -kv.
+
+  rcs -ko sets the default keyword substitution to be in the style of co -ko,
+  and similarly for the other -k options.  This can be useful with binary file
+  formats that cannot tolerate changing the lengths of keyword strings.
+  However it also renders a RCS file readable only by RCS version 5 or later.
+  Use rcs -kkv to restore the usual default substitution.
+
+  RCS can now be used by development groups that span timezone boundaries.
+  All times are now displayed in GMT, and GMT is the default timezone.
+  To use local time with co -d, append ` LT' to the time.
+  When interchanging RCS files with sites running older versions of RCS,
+  time stamp discrepancies may prevent checkins; to work around this,
+  use `ci -d' with a time slightly in the future.
+
+  Dates are now displayed using four-digit years, not two-digit years.
+  Years given in -d options must now have four digits.
+  This change is required for RCS to continue to work after 1999/12/31.
+  The form of dates in version 5 RCS files will not change until 2000/01/01,
+  so in the meantime RCS files can still be interchanged with sites
+  running older versions of RCS.  To make room for the longer dates,
+  rlog now outputs `lines: +A -D' instead of `lines added/del: A/D'.
+
+  To help prevent diff programs that are broken or have run out of memory
+  from trashing an RCS file, ci now checks diff output more carefully.
+
+  ci -k now handles the Log keyword, so that checking in a file
+  with -k does not normally alter the file's contents.
+
+  RCS no longer outputs white space at the ends of lines
+  unless the original working file had it.
+  For consistency with other keywords,
+  a space, not a tab, is now output after `$Log:'.
+  Rlog now puts lockers and symbolic names on separate lines in the output
+  to avoid generating lines that are too long.
+  A similar fix has been made to lists in the RCS files themselves.
+
+  RCS no longer outputs the string `Locker: ' when expanding Header or Id
+  keywords.  This saves space and reverts back to version 3 behavior.
+
+  The default branch is not put into the RCS file unless it is nonempty.
+  Therefore, files generated by RCS version 5 can be read by RCS version 3
+  unless they use the default branch feature introduced in version 4.
+  This fixes a compatibility problem introduced by version 4.
+
+  RCS can now emulate older versions of RCS; see `co -V'.
+  This may be useful to overcome compatibility problems
+  due to the above changes.
+
+  Programs like Emacs can now interact with RCS commands via a pipe:
+  the new -I option causes ci, co, and rcs to run interactively,
+  even if standard input is not a terminal.
+  These commands now accept multiple inputs from stdin separated by `.' lines.
+
+  ci now silently ignores the -t option if the RCS file already exists.
+  This simplifies some shell scripts and improves security in setuid sites.
+
+  Descriptive text may be given directly in an argument of the form -t-string.
+
+  The character set for symbolic names has been upgraded
+  from Ascii to ISO 8859.
+
+  rcsdiff now passes through all options used by GNU diff;
+  this is a longer list than 4.3BSD diff.
+
+  merge's new -L option gives tags for merge's overlap report lines.
+  This ability used to be present in a different, undocumented form;
+  the new form is chosen for compatibility with GNU diff3's -L option.
+
+  rcsmerge and merge now have a -q option, just like their siblings do.
+
+  RCS now attempts to ignore parts of an RCS file that look like they come
+  from a future version of RCS.
+
+  When properly configured, RCS now strictly conforms with Posix 1003.1-1990.
+  RCS can still be compiled in non-Posix traditional Unix environments,
+  and can use common BSD and USG extensions to Posix.
+  RCS is a conforming Standard C program, and also compiles under traditional C.
+
+  Arbitrary limits on internal table sizes have been removed.
+  The only limit now is the amount of memory available via malloc().
+
+  File temporaries, lock files, signals, and system call return codes
+  are now handled more cleanly, portably, and quickly.
+  Some race conditions have been removed.
+
+  A new compile-time option RCSPREFIX lets administrators avoid absolute path
+  names for subsidiary programs, trading speed for flexibility.
+
+  The configuration procedure is now more automatic.
+
+  Snooping has been removed.
+
+
+Version 4 was the first version distributed by FSF.
+Beside bug fixes, features new to RCS version 4 include:
+
+  The notion of default branch has been added; see rcs -b.
+
+
+Version 3 was included in the 4.3BSD distribution.
+
+
+Further projects:
+
+  Add format options for finer control over the output of ident and rlog.
+
+  Be able to redo the most recent checkin with minor changes.
+
+  Add a `-' option to take the list of pathnames from standard input.
+  Perhaps the pathnames should be null-terminated, not newline-terminated,
+  so that pathnames that contain newlines are handled properly.
+
+  Add general options so that rcsdiff and rcsmerge can pass arbitrary options
+  to its subsidiary co and diff processes.  E.g.
+
+       -.OPTION to pass OPTION to the subsidiary `co'
+       -/OPTION to pass OPTION to the subsidiary `diff' (for rcsdiff only)
+
+  For example:
+
+       rcsdiff -.-d"1991/02/09 18:09" -.-sRel -/+unified -/-C -/5 -/-d foo.c
+
+  invokes `co -d"1991/02/09 18:09" -sRel ...' and `diff +unified -C 5 -d ...'.
+  To pass an option to just one subsidiary `co', put the -. option
+  after the corresponding -r option.  For example:
+
+       rcsmerge -r1.4 -.-ko -r1.8 -.-kkv foo.c
+
+  passes `-ko' to the first subsidiary `co', and `-kkv' to the second one.
+
+
+  Permit multiple option-pathname pairs, e.g. co -r1.4 a -r1.5 b.
+
+  Add ways to specify the earliest revision, the most recent revision,
+  the earliest or latest revision on a particular branch, and
+  the parent or child of some other revision.
+
+  If a user has multiple locks, perhaps ci should fall back on ci -k's
+  method to figure out which revision to use.
+
+  Symbolic names need not refer to existing branches and revisions.
+  rcs(1)'s BUGS section says this is a bug.  Is it?  If so, it should be fixed.
+
+  Write an rcsck program that repairs corrupted RCS files,
+  much as fsck repairs corrupted file systems.
+
+  Clean up the source code with a consistent indenting style.
+
+  Update the date parser to use the more modern getdate.y by Bellovin,
+  Salz, and Berets, or the even more modern getdate by Moraes.  None of
+  these getdate implementations are as robust as RCS's old warhorse in
+  avoiding problems like arithmetic overflow, so they'll have to be
+  fixed first.
+
+  Break up the code into a library so that it's easier to write new programs
+  that manipulate RCS files, and so that useless code is removed from the
+  existing programs.  For example, the rcs command contains unnecessary
+  keyword substitution baggage, and the merge command can be greatly pruned.
+
+  Make it easier to use your favorite text editor to edit log messages,
+  etc. instead of having to type them in irretrievably at the terminal.
+
+The following projects require a change to RCS file format,
+and thus must wait until at least RCS version 6.
+
+  Be able to store RCS files in compressed format.
+  Don't bother to use a .Z extension that would exceed file name length limits;
+  just look at the magic number.
+
+  Add locker commentary, e.g. `co -l -m"checkout to fix merge bug" foo'
+  to tell others why you checked out `foo'.
+  Also record the time when the revision was locked,
+  and perhaps the working pathname (if applicable).
+
+  Let the user mark an RCS revision as deleted; checking out such a revision
+  would result in no working file.  Similarly, using `co -d' with a date either
+  before the initial revision or after the file was marked deleted should
+  remove the working file.  For extra credit, extend the notion of `deleted' to
+  include `renamed'.  RCS should support arbitrary combinations of renaming and
+  deletion, e.g. renaming A to B and B to A, checking in new revisions to both
+  files, and then renaming them back.
+
+  Use a better scheme for locking revisions; the current scheme requires
+  changing the RCS file just to lock or unlock a revision.
+  The new scheme should coexist as well as possible with older versions of RCS,
+  and should avoid the rare NFS bugs mentioned in rcsedit.c.
+
+  Add rcs options for changing keyword names, e.g. XConsortium instead of Id.
+
+  Add frozen branches a la SCCS.  In general, be able to emulate all of
+  SCCS, so that an SCCS-to-RCS program can be practical.
+
+  Add support for distributed RCS, where widely separated
+  users cannot easily access each others' RCS files,
+  and must periodically distribute and reconcile new revisions.
+
+  Be able to create empty branches.
+
+  Improve RCS's method for storing binary files.
+  Although it is more efficient than SCCS's,
+  the diff algorithm is still line oriented,
+  and often generates long output for minor changes to an executable file.
+
+  Add a new `-kb' expansion for binary files on non-Posix hosts
+  that distinguish between text and binary I/O.
+  The current `text_work_stdio' compile-time switch is too inflexible.
+  This fix either requires nonstandard primitives like DOS's setmode(),
+  or requires that `-kb' be specified on initial checkin and never changed.
+  From the user's point of view, it would be best if
+  RCS detected and handled binary files without human intervention,
+  switching expansion methods as needed from revision to revision.
+
+  Extend the grammar of RCS files so that keywords need not be in a fixed order.
+
+  Internationalize messages; unfortunately, there's no common standard yet.
+  This requires a change in RCS file format because of the
+  `empty log message' and `checked in with -k' hacks inside RCS files.
+
+
+Credits:
+
+  RCS was designed and built by Walter F. Tichy of Purdue University.
+  RCS version 3 was released in 1983.
+
+  Adam Hammer, Thomas Narten, and Dan Trinkle of Purdue supported RCS through
+  version 4.3, released in 1990.  Guy Harris of Sun contributed many porting
+  fixes.  Paul Eggert of System Development Corporation contributed bug fixes
+  and tuneups.  Jay Lepreau contributed 4.3BSD support.
+
+  Paul Eggert of Twin Sun wrote the changes for RCS version 5, released in 1991.
+  Rich Braun of Kronos and Andy Glew of Intel contributed ideas for new options.
+  Bill Hahn of Stratus contributed ideas for setuid support.
+  Ideas for piece tables came from Joe Berkovitz of Stratus and Walter F. Tichy.
+  Matt Cross of Stratus contributed test case ideas.
+  Adam Hammer of Purdue QAed.
diff --git a/usr/src/contrib/rcs-V5.6/man/co.1 b/usr/src/contrib/rcs-V5.6/man/co.1
new file mode 100644 (file)
index 0000000..d9ce65e
--- /dev/null
@@ -0,0 +1,569 @@
+.de Id
+.ds Rv \\$3
+.ds Dt \\$4
+..
+.Id $Id: co.1,v 5.7 1991/08/19 03:13:55 eggert Exp $
+.ds g \&\s-1UTC\s0
+.ds r \&\s-1RCS\s0
+.if n .ds - \%--
+.if t .ds - \(em
+.TH CO 1 \*(Dt GNU
+.SH NAME
+co \- check out RCS revisions
+.SH SYNOPSIS
+.B co
+.RI [ options ] " file " .\|.\|.
+.SH DESCRIPTION
+.B co
+retrieves a revision from each \*r file and stores it into
+the corresponding working file.
+.PP
+Pathnames matching an \*r suffix denote \*r files;
+all others denote working files.
+Names are paired as explained in
+.BR ci (1).
+.PP
+Revisions of an \*r 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.  Checkout with locking
+fails if the revision to be checked out is currently locked by another user.
+(A lock may be broken with
+.BR rcs "(1).)\ \&"
+Checkout with locking also requires the caller to be on the access list of
+the \*r 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.
+.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,
+.B co
+retrieves the latest revision
+that satisfies all of them.
+If none of the selection options
+is specified,
+.B co
+retrieves the latest revision
+on the default branch (normally the trunk, see the
+.B \-b
+option of
+.BR rcs (1)).
+A revision or branch number may be attached
+to any of the options
+.BR \-f ,
+.BR \-I ,
+.BR \-l ,
+.BR \-M ,
+.BR \-p ,
+.BR \-q ,
+.BR \-r ,
+or
+.BR \-u .
+The options
+.B \-d
+(date),
+.B \-s
+(state), and
+.B \-w
+(author)
+retrieve from a single branch, the
+.I selected
+branch,
+which is either specified by one of
+.BR \-f,
+\&.\|.\|.,
+.BR \-u ,
+or the default branch.
+.PP
+A
+.B co
+command applied to an \*r
+file with no revisions creates a zero-length working file.
+.B co
+always performs keyword substitution (see below).
+.SH OPTIONS
+.TP
+.BR \-r [\f2rev\fP]
+retrieves the latest revision whose number is less than or equal to
+.I rev.
+If
+.I rev
+indicates a branch rather than a revision,
+the latest revision on that branch is retrieved.
+If
+.I rev
+is omitted, the latest revision on the default branch
+(see the
+.B \-b
+option of
+.BR rcs (1))
+is retrieved.
+If
+.I rev
+is
+.BR $ ,
+.B co
+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.  The numeric equivalent of a symbolic field
+is specified with the
+.B \-n
+option of the commands
+.BR ci (1)
+and
+.BR rcs (1).
+.TP
+.BR \-l [\f2rev\fP]
+same as
+.BR \-r ,
+except that it also locks the retrieved revision for
+the caller.
+.TP
+.BR \-u [\f2rev\fP]
+same as
+.BR \-r ,
+except that it unlocks the retrieved revision if it was
+locked by the caller.  If
+.I rev
+is omitted,
+.B \-u
+retrieves the revision locked by the caller, if there is one; otherwise,
+it retrieves the latest revision on the default branch.
+.TP
+.BR \-f [\f2rev\fP]
+forces the overwriting of the working file;
+useful in connection with
+.BR \-q .
+See also
+.SM "FILE MODES"
+below.
+.TP
+.B \-kkv
+Generate keyword strings using the default form, e.g.\&
+.B "$\&Revision: \*(Rv $"
+for the
+.B Revision
+keyword.
+A locker's name is inserted in the value of the
+.BR Header ,
+.BR Id ,
+and
+.B Locker
+keyword strings
+only as a file is being locked,
+i.e. by
+.B "ci\ \-l"
+and
+.BR "co\ \-l".
+This is the default.
+.TP
+.B \-kkvl
+Like
+.BR \-kkv ,
+except that a locker's name is always inserted
+if the given revision is currently locked.
+.TP
+.BR \-kk
+Generate only keyword names in keyword strings; omit their values.
+See
+.SM "KEYWORD SUBSTITUTION"
+below.
+For example, for the
+.B Revision
+keyword, generate the string
+.B $\&Revision$
+instead of
+.BR "$\&Revision: \*(Rv $".
+This option is useful to ignore differences due to keyword substitution
+when comparing different revisions of a file.
+.TP
+.BR \-ko
+Generate the old keyword string,
+present in the working file just before it was checked in.
+For example, for the
+.B Revision
+keyword, generate the string
+.B "$\&Revision: 1.1 $"
+instead of
+.B "$\&Revision: \*(Rv $"
+if that is how the string appeared when the file was checked in.
+This can be useful for binary file formats
+that cannot tolerate any changes to substrings
+that happen to take the form of keyword strings.
+.TP
+.BR \-kv
+Generate only keyword values for keyword strings.
+For example, for the
+.B Revision
+keyword, generate the string
+.B \*(Rv
+instead of
+.BR "$\&Revision: \*(Rv $".
+This can help generate files in programming languages where it is hard to
+strip keyword delimiters like
+.B "$\&Revision:\ $"
+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
+.BR \-l ,
+and the owner write permission of the working file is turned off;
+to edit the file later, check it out again without
+.BR \-kv .
+.TP
+.BR \-p [\f2rev\fP]
+prints the retrieved revision on the standard output rather than storing it
+in the working file.
+This option is useful when
+.B co
+is part of a pipe.
+.TP
+.BR \-q [\f2rev\fP]
+quiet mode; diagnostics are not printed.
+.TP
+.BR \-I [\f2rev\fP]
+interactive mode;
+the user is prompted and questioned
+even if the standard input is not a terminal.
+.TP
+.BI \-d date
+retrieves the latest revision on the selected branch whose checkin date/time is
+less than or equal to
+.I date.
+The date and time may be given in free format.
+The time zone
+.B LT
+stands for local time;
+other common time zone names are understood.
+For example, the following
+.IR date s
+are equivalent
+if local time is January 11, 1990, 8pm Pacific Standard Time,
+eight hours west of Coordinated Universal Time (\*g):
+.RS
+.LP
+.RS
+.nf
+.ta \w'\f3Thu, 11 Jan 1990 20:00:00 \-0800\fP  'u
+.ne 9
+\f38:00 pm lt\fP
+\f34:00 AM, Jan. 12, 1990\fP   note: default is \*g
+\f31990/01/12 04:00:00\fP      \*r date format
+\f3Thu Jan 11 20:00:00 1990 LT\fP      output of \f3ctime\fP(3) + \f3LT\fP
+\f3Thu Jan 11 20:00:00 PST 1990\fP     output of \f3date\fP(1)
+\f3Fri Jan 12 04:00:00 GMT 1990\fP
+\f3Thu, 11 Jan 1990 20:00:00 \-0800\fP
+\f3Fri-JST, 1990, 1pm Jan 12\fP
+\f312-January-1990, 04:00-WET\fP
+.ta 4n +4n +4n +4n
+.fi
+.RE
+.LP
+Most fields in the date and time may be defaulted.
+The default time zone is \*g.
+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, the date
+.B "20, 10:30"
+defaults to
+10:30:00 \*g of the 20th of the \*g time zone's current month and year.
+The date/time must be quoted if it contains spaces.
+.RE
+.TP
+.BR \-M [\f2rev\fP]
+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
+.BR make (1).
+.TP
+.BI \-s state
+retrieves the latest revision on the selected branch whose state is set to
+.I state.
+.TP
+.BR \-w [\f2login\fP]
+retrieves the latest revision on the selected branch which was checked in
+by the user with login name
+.I login.
+If the argument
+.I login
+is
+omitted, the caller's login is assumed.
+.TP
+.BI \-j joinlist
+generates a new revision which is the join of the revisions on
+.I joinlist.
+This option is largely obsoleted by
+.BR rcsmerge (1)
+but is retained for backwards compatibility.
+.RS
+.PP
+The
+.I joinlist
+is a comma-separated list of pairs of the form
+.IB rev2 : rev3,
+where
+.I rev2
+and
+.I rev3
+are (symbolic or numeric)
+revision numbers.
+For the initial such pair,
+.I rev1
+denotes the revision selected
+by the above options
+.BR \-f,
+\&.\|.\|.,
+.BR \-w .
+For all other pairs,
+.I rev1
+denotes the revision generated by the previous pair.
+(Thus, the output
+of one join becomes the input to the next.)
+.PP
+For each pair,
+.B co
+joins revisions
+.I rev1
+and
+.I rev3
+with respect to
+.I rev2.
+This means that all changes that transform
+.I rev2
+into
+.I rev1
+are applied to a copy of
+.I rev3.
+This is particularly useful if
+.I rev1
+and
+.I rev3
+are the ends of two branches that have
+.I rev2
+as a common ancestor.  If
+.IR rev1 < rev2 < rev3
+on the same branch,
+joining generates a new revision which is like
+.I rev3,
+but with all changes that lead from
+.I rev1
+to
+.I rev2
+undone.
+If changes from
+.I rev2
+to
+.I rev1
+overlap with changes from
+.I rev2
+to
+.I rev3,
+.B co
+reports overlaps as described in
+.BR merge (1).
+.PP
+For the initial pair,
+.I rev2
+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
+.B \-l
+and
+.B \-u
+lock or unlock
+.I rev1.
+.RE
+.TP
+.BI \-V n
+Emulate \*r version
+.I n,
+where
+.I n
+may be
+.BR 3 ,
+.BR 4 ,
+or
+.BR 5 .
+This may be useful when interchanging \*r files with others who are
+running older versions of \*r.
+To see which version of \*r your correspondents are running, have them invoke
+.B rlog
+on an \*r file;
+if none of the first few lines of output contain the string
+.B branch:
+it is version 3;
+if the dates' years have just two digits, it is version 4;
+otherwise, it is version 5.
+An \*r file generated while emulating version 3 will lose its default branch.
+An \*r revision generated while emulating version 4 or earlier will have
+a timestamp that is off by up to 13 hours.
+A revision extracted while emulating version 4 or earlier will contain
+dates of the form
+.IB yy / mm / dd
+instead of
+.IB yyyy / mm / dd
+and may also contain different white space in the substitution for
+.BR $\&Log$ .
+.TP
+.BI \-x "suffixes"
+Use
+.I suffixes
+to characterize \*r files.
+See
+.BR ci (1)
+for details.
+.SH "KEYWORD SUBSTITUTION"
+Strings of the form
+.BI $ keyword $
+and
+.BI $ keyword : .\|.\|. $
+embedded in
+the text are replaced
+with strings of the form
+.BI $ keyword : value $
+where
+.I keyword
+and
+.I value
+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
+.BI $ keyword $ .
+On checkout,
+.B co
+replaces these strings with strings of the form
+.BI $ keyword : value $ .
+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
+.B \-k
+options.
+.PP
+Keywords and their corresponding values:
+.TP
+.B $\&Author$
+The login name of the user who checked in the revision.
+.TP
+.B $\&Date$
+The date and time (\*g) the revision was checked in.
+.TP
+.B $\&Header$
+A standard header containing the full pathname of the \*r file, the
+revision number, the date (\*g), the author, the state,
+and the locker (if locked).
+.TP
+.B $\&Id$
+Same as
+.BR $\&Header$ ,
+except that the \*r filename is without a path.
+.TP
+.B $\&Locker$
+The login name of the user who locked the revision (empty if not locked).
+.TP
+.B $\&Log$
+The log message supplied during checkin, preceded by a header
+containing the \*r filename, the revision number, the author, and the date
+(\*g).
+Existing log messages are
+.I not
+replaced.
+Instead, the new log message is inserted after
+.BR $\&Log: .\|.\|. $ .
+This is useful for
+accumulating a complete change log in a source file.
+.TP
+.B $\&RCSfile$
+The name of the \*r file without a path.
+.TP
+.B $\&Revision$
+The revision number assigned to the revision.
+.TP
+.B $\&Source$
+The full pathname of the \*r file.
+.TP
+.B $\&State$
+The state assigned to the revision with the
+.B \-s
+option of
+.BR rcs (1)
+or
+.BR ci (1).
+.SH "FILE MODES"
+The working file inherits the read and execute permissions from the \*r
+file.  In addition, the owner write permission is turned on, unless
+.B \-kv
+is set or the file
+is checked out unlocked and locking is set to strict (see
+.BR rcs (1)).
+.PP
+If a file with the name of the working file exists already and has write
+permission,
+.B co
+aborts the checkout,
+asking beforehand if possible.
+If the existing working file is
+not writable or
+.B \-f
+is given, the working file is deleted without asking.
+.SH FILES
+.B co
+accesses files much as
+.BR ci (1)
+does, except that it does not need to read the working file.
+.SH ENVIRONMENT
+.TP
+.B \s-1RCSINIT\s0
+options prepended to the argument list, separated by spaces.
+See
+.BR ci (1)
+for details.
+.SH DIAGNOSTICS
+The \*r 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.
+.SH IDENTIFICATION
+Author: Walter F. Tichy.
+.br
+Revision Number: \*(Rv; Release Date: \*(Dt.
+.br
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.br
+Copyright \(co 1990, 1991 by Paul Eggert.
+.SH "SEE ALSO"
+ci(1), ctime(3), date(1), ident(1), make(1),
+rcs(1), rcsdiff(1), rcsintro(1), rcsmerge(1), rlog(1),
+rcsfile(5)
+.br
+Walter F. Tichy,
+\*r\*-A System for Version Control,
+.I "Software\*-Practice & Experience"
+.BR 15 ,
+7 (July 1985), 637-654.
+.SH LIMITS
+Links to the \*r and working files are not preserved.
+.PP
+There is no way to selectively suppress the expansion of keywords, except
+by writing them differently.  In nroff and troff, this is done by embedding the
+null-character
+.B \e&
+into the keyword.
+.SH BUGS
+The
+.B \-d
+option sometimes gets confused, and accepts no date before 1970.
+.br
diff --git a/usr/src/contrib/rcs-V5.6/man/ident.1 b/usr/src/contrib/rcs-V5.6/man/ident.1
new file mode 100644 (file)
index 0000000..37c8eda
--- /dev/null
@@ -0,0 +1,76 @@
+.de Id
+.ds Rv \\$3
+.ds Dt \\$4
+.ds iD \\$3 \\$4 \\$5 \\$6 \\$7
+..
+.Id $Id: ident.1,v 5.0 1990/08/22 09:09:36 eggert Exp $
+.ds r \s-1RCS\s0
+.if n .ds - \%--
+.if t .ds - \(em
+.TH IDENT 1 \*(Dt GNU
+.SH NAME
+ident \- identify files
+.SH SYNOPSIS
+.B ident
+[
+.B \-q
+] [
+.I file
+\&.\|.\|. ]
+.SH DESCRIPTION
+.B ident
+searches for all occurrences of the pattern
+.BI $ keyword : .\|.\|. $
+in the named files or, if no file name appears, the standard input.
+.PP
+These patterns are normally inserted automatically by the \*r command
+.BR co (1),
+but can also be inserted manually.
+The option
+.B \-q
+suppresses
+the warning given if there are no patterns in a file.
+.PP
+.B ident
+works on text files as well as object files and dumps.
+For example, if the C program in
+.B f.c
+contains
+.IP
+\f3char rcsid[] = \&"$\&Id: f.c,v \*(iD $\&";\fP
+.LP
+and
+.B f.c
+is compiled into
+.BR f.o ,
+then the command
+.IP
+.B "ident  f.c  f.o"
+.LP
+will output
+.nf
+.IP
+.ft 3
+f.c:
+    $\&Id: f.c,v \*(iD $
+f.o:
+    $\&Id: f.c,v \*(iD $
+.ft
+.fi
+.SH IDENTIFICATION
+Author: Walter F. Tichy.
+.br
+Revision Number: \*(Rv; Release Date: \*(Dt.
+.br
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.br
+Copyright \(co 1990 by Paul Eggert.
+.SH "SEE ALSO"
+ci(1), co(1), rcs(1), rcsdiff(1), rcsintro(1), rcsmerge(1), rlog(1),
+rcsfile(5)
+.br
+Walter F. Tichy,
+\*r\*-A System for Version Control,
+.I "Software\*-Practice & Experience"
+.BR 15 ,
+7 (July 1985), 637-654.
diff --git a/usr/src/contrib/rcs-V5.6/man/merge.1 b/usr/src/contrib/rcs-V5.6/man/merge.1
new file mode 100644 (file)
index 0000000..8b1957f
--- /dev/null
@@ -0,0 +1,102 @@
+.de Id
+.ds Rv \\$3
+.ds Dt \\$4
+..
+.Id $Id: merge.1,v 5.3 1991/02/28 19:18:45 eggert Exp $
+.TH MERGE 1 \*(Dt GNU
+.SH NAME
+merge \- three-way file merge
+.SH SYNOPSIS
+.B merge
+[
+.B \-L
+.I label1
+[
+.B \-L
+.I label3
+] ] [
+.B \-p
+] [
+.B \-q
+]
+.I "file1 file2 file3"
+.SH DESCRIPTION
+.B merge
+incorporates all changes that lead from
+.I file2
+to
+.I file3
+into
+.IR file1 .
+The result goes to standard output if
+.B \-p
+is present, into
+.I file1
+otherwise.
+.B merge
+is useful for combining separate changes to an original.  Suppose
+.I file2
+is the original, and both
+.I file1
+and
+.I file3
+are modifications of
+.IR file2 .
+Then
+.B merge
+combines both changes.
+.PP
+An overlap occurs if both
+.I file1
+and
+.I file3
+have changes in a common segment of lines.
+On a few older hosts where
+.B diff3
+does not support the
+.B \-E
+option,
+.B merge
+does not detect overlaps, and merely supplies the changed lines from
+.I file3.
+On most hosts, if overlaps occur,
+.B merge
+outputs a message (unless the
+.B \-q
+option is given),
+and includes both alternatives
+in the result.  The alternatives are delimited as follows:
+.LP
+.RS
+.nf
+.BI <<<<<<< " file1"
+.I "lines in file1"
+.B "======="
+.I "lines in file3"
+.BI >>>>>>> " file3"
+.RE
+.fi
+.LP
+If there are overlaps, the user should edit the result and delete one of the
+alternatives.
+If the
+.BI \-L "\ label1"
+and
+.BI \-L "\ label3"
+options are given, the labels are output in place of the names
+.I file1
+and
+.I file3
+in overlap reports.
+.SH DIAGNOSTICS
+Exit status is 0 for no overlaps, 1 for some overlaps, 2 for trouble.
+.SH IDENTIFICATION
+Author: Walter F. Tichy.
+.br
+Revision Number: \*(Rv; Release Date: \*(Dt.
+.br
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.br
+Copyright \(co 1990, 1991 by Paul Eggert.
+.SH SEE ALSO
+diff3(1), diff(1), rcsmerge(1), co(1).
diff --git a/usr/src/contrib/rcs-V5.6/man/rcs.1 b/usr/src/contrib/rcs-V5.6/man/rcs.1
new file mode 100644 (file)
index 0000000..9866a9c
--- /dev/null
@@ -0,0 +1,397 @@
+.de Id
+.ds Rv \\$3
+.ds Dt \\$4
+..
+.Id $Id: rcs.1,v 5.6 1991/09/26 23:16:17 eggert Exp $
+.ds r \&\s-1RCS\s0
+.if n .ds - \%--
+.if t .ds - \(em
+.TH RCS 1 \*(Dt GNU
+.SH NAME
+rcs \- change RCS file attributes
+.SH SYNOPSIS
+.B rcs
+.RI [ " options " ] " file " .\|.\|.
+.SH DESCRIPTION
+.B rcs
+creates new \*r files or changes attributes of existing ones.
+An \*r file contains multiple revisions of text,
+an access list, a change log,
+descriptive text,
+and some control attributes.
+For
+.B 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
+.B \-i
+option is present.
+.PP
+Pathnames matching an \*r suffix denote \*r files;
+all others denote working files.
+Names are paired as explained in
+.BR ci (1).
+Revision numbers use the syntax described in
+.BR ci (1).
+.SH OPTIONS
+.TP
+.B \-i
+Create and initialize a new \*r file, but do not deposit any revision.
+If the \*r file has no path prefix, try to place it
+first into the subdirectory
+.BR ./RCS ,
+and then into the current directory.
+If the \*r file
+already exists, print an error message.
+.TP
+.BI \-a "logins"
+Append the login names appearing in the comma-separated list
+.I logins
+to the access list of the \*r file.
+.TP
+.BI \-A "oldfile"
+Append the access list of
+.I oldfile
+to the access list of the \*r file.
+.TP
+.BR \-e [\f2logins\fP]
+Erase the login names appearing in the comma-separated list
+.I logins
+from the access list of the \*r file.
+If
+.I logins
+is omitted, erase the entire access list.
+.TP
+.BR \-b [\f2rev\fP]
+Set the default branch to
+.IR rev .
+If
+.I rev
+is omitted, the default
+branch is reset to the (dynamically) highest branch on the trunk.
+.TP
+.BI \-c string
+sets the comment leader to
+.IR string .
+The comment leader
+is printed before every log message line generated by the keyword
+.B $\&Log$
+during checkout (see
+.BR co (1)).
+This is useful for programming
+languages without multi-line comments.
+An initial
+.B ci ,
+or an
+.B "rcs\ \-i"
+without
+.BR \-c ,
+guesses the comment leader from the suffix of the working file.
+.TP
+.BI \-k subst
+Set the default keyword substitution to
+.IR subst .
+The effect of keyword substitution is described in
+.BR co (1).
+Giving an explicit
+.B \-k
+option to
+.BR co ,
+.BR rcsdiff ,
+and
+.B rcsmerge
+overrides this default.
+Beware
+.BR "rcs\ \-kv",
+because
+.B \-kv
+is incompatible with
+.BR "co\ \-l".
+Use
+.B "rcs\ \-kkv"
+to restore the normal default keyword substitution.
+.TP
+.BR \-l [\f2rev\fP]
+Lock the revision with number
+.IR rev .
+If a branch is given, lock the latest revision on that branch.
+If
+.I rev
+is omitted, lock the latest revision on the default branch.
+Locking prevents overlapping changes.
+A lock is removed with
+.B ci
+or
+.B "rcs\ \-u"
+(see below).
+.TP
+.BR \-u [\f2rev\fP]
+Unlock the revision with number
+.IR rev .
+If a branch is given, unlock the latest revision on that branch.
+If
+.I rev
+is omitted, remove the latest lock held by the caller.
+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 by end-of-file or by a line containing
+.BR \&. "\ by"
+itself.
+.TP
+.B \-L
+Set locking to
+.IR strict .
+Strict locking means that the owner
+of an \*r file is not exempt from locking for checkin.
+This option should be used for files that are shared.
+.TP
+.B \-U
+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
+.I not
+be used for files that are shared.
+Whether default locking is strict is determined by your system administrator,
+but it is normally strict.
+.TP
+\f3\-m\fP\f2rev\fP\f3:\fP\f2msg\fP
+Replace revision
+.IR rev 's
+log message with
+.IR msg .
+.TP
+\f3\-n\fP\f2name\fP[\f3:\fP[\f2rev\fP]]
+Associate the symbolic name
+.I name
+with the branch or
+revision
+.IR rev .
+Delete the symbolic name if both
+.B :
+and
+.I rev
+are omitted; otherwise, print an error message if
+.I name
+is already associated with
+another number.
+If
+.I rev
+is symbolic, it is expanded before association.
+A
+.I rev
+consisting of a branch number followed by a
+.B .\&
+stands for the current latest revision in the branch.
+A
+.B :
+with an empty
+.I rev
+stands for the current latest revision on the default branch,
+normally the trunk.
+For example,
+.BI "rcs\ \-n" name ":\ RCS/*"
+associates
+.I name
+with the current latest revision of all the named \*r files;
+this contrasts with
+.BI "rcs\ \-n" name ":$\ RCS/*"
+which associates
+.I name
+with the revision numbers extracted from keyword strings
+in the corresponding working files.
+.TP
+\f3\-N\fP\f2name\fP[\f3:\fP[\f2rev\fP]]
+Act like
+.BR \-n ,
+except override any previous assignment of
+.IR name .
+.TP
+.BI \-o range
+deletes (\*(lqoutdates\*(rq) the revisions given by
+.IR range .
+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
+.IB rev1 : rev2
+means
+revisions
+.I rev1
+to
+.I rev2
+on the same branch,
+.BI : rev
+means from the beginning of the branch containing
+.I rev
+up to and including
+.IR rev ,
+and
+.IB rev :
+means
+from revision
+.I rev
+to the end of the branch containing
+.IR rev .
+None of the outdated revisions may have branches or locks.
+.TP
+.B \-q
+Run quietly; do not print diagnostics.
+.TP
+.B \-I
+Run interactively, even if the standard input is not a terminal.
+.TP
+.B \-s\f2state\fP\f1[\fP:\f2rev\fP\f1]\fP
+Set the state attribute of the revision
+.I rev
+to
+.I state .
+If
+.I rev
+is a branch number, assume the latest revision on that branch.
+If
+.I rev
+is omitted, assume the latest revision on the default branch.
+Any identifier is acceptable for
+.IR state .
+A useful set of states
+is
+.B Exp
+(for experimental),
+.B Stab
+(for stable), and
+.B Rel
+(for
+released).
+By default,
+.BR ci (1)
+sets the state of a revision to
+.BR Exp .
+.TP
+.BR \-t [\f2file\fP]
+Write descriptive text from the contents of the named
+.I file
+into the \*r file, deleting the existing text.
+The
+.IR file
+pathname may not begin with
+.BR \- .
+If
+.I file
+is omitted, obtain the text from standard input,
+terminated by end-of-file or by a line containing
+.BR \&. "\ by"
+itself.
+Prompt for the text if interaction is possible; see
+.BR \-I .
+With
+.BR \-i ,
+descriptive text is obtained
+even if
+.B \-t
+is not given.
+.TP
+.BI \-t\- string
+Write descriptive text from the
+.I string
+into the \*r file, deleting the existing text.
+.TP
+.BI \-V n
+Emulate \*r version
+.IR n .
+See
+.BR co (1)
+for details.
+.TP
+.BI \-x "suffixes"
+Use
+.I suffixes
+to characterize \*r files.
+See
+.BR ci (1)
+for details.
+.SH COMPATIBILITY
+The
+.BI \-b rev
+option generates an \*r file that cannot be parsed by \*r version 3 or earlier.
+.PP
+The
+.BI \-k subst
+options (except
+.BR \-kkv )
+generate an \*r file that cannot be parsed by \*r version 4 or earlier.
+.PP
+Use
+.BI "rcs \-V" n
+to make an \*r file acceptable to \*r version
+.I n
+by discarding information that would confuse version
+.IR n .
+.PP
+\*r version 5.5 and earlier does not support the
+.B \-x
+option, and requires a
+.B ,v
+suffix on an \*r pathname.
+.SH FILES
+.B rcs
+accesses files much as
+.BR ci (1)
+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 the working file unless a revision number of
+.B $
+is specified.
+.SH ENVIRONMENT
+.TP
+.B \s-1RCSINIT\s0
+options prepended to the argument list, separated by spaces.
+See
+.BR ci (1)
+for details.
+.SH DIAGNOSTICS
+The \*r pathname and the revisions outdated are written to
+the diagnostic output.
+The exit status is zero if and only if all operations were successful.
+.SH IDENTIFICATION
+Author: Walter F. Tichy.
+.br
+Revision Number: \*(Rv; Release Date: \*(Dt.
+.br
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.br
+Copyright \(co 1990, 1991 by Paul Eggert.
+.SH "SEE ALSO"
+co(1), ci(1), ident(1), rcsdiff(1), rcsintro(1), rcsmerge(1), rlog(1),
+rcsfile(5)
+.br
+Walter F. Tichy,
+\*r\*-A System for Version Control,
+.I "Software\*-Practice & Experience"
+.BR 15 ,
+7 (July 1985), 637-654.
+.SH BUGS
+The separator for revision ranges in the
+.B \-o
+option used to be
+.B \-
+instead of
+.BR : ,
+but this leads to confusion when symbolic names contain
+.BR \- .
+For backwards compatibility
+.B "rcs \-o"
+still supports the old
+.B \-
+separator, but it warns about this obsolete use.
+.PP
+Symbolic names need not refer to existing revisions or branches.
+For example, the
+.B \-o
+option does not remove symbolic names for the outdated revisions; you must use
+.B \-n
+to remove the names.
+.br
diff --git a/usr/src/contrib/rcs-V5.6/man/rcsclean.1 b/usr/src/contrib/rcs-V5.6/man/rcsclean.1
new file mode 100644 (file)
index 0000000..07ed722
--- /dev/null
@@ -0,0 +1,177 @@
+.de Id
+.ds Rv \\$3
+.ds Dt \\$4
+..
+.Id $Id: rcsclean.1,v 1.8 1991/11/03 01:09:19 eggert Exp $
+.ds r \&\s-1RCS\s0
+.if n .ds - \%--
+.if t .ds - \(em
+.TH RCSCLEAN 1 \*(Dt GNU
+.SH NAME
+rcsclean \- clean up working files
+.SH SYNOPSIS
+.B rcsclean
+.RI [ options "] [ " file " .\|.\|. ]"
+.SH DESCRIPTION
+.B rcsclean
+removes working files that were checked out and never modified.
+For each
+.I file
+given,
+.B rcsclean
+compares the working file and a revision in the corresponding
+\*r file.  If it finds a difference, it does nothing.
+Otherwise, it first unlocks the revision if the
+.B \-u
+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
+.B "rcs \-u"
+and
+.B "rm \-f"
+commands on the standard output.
+.PP
+If no
+.I file
+is given, all working files in the current directory are cleaned.
+Pathnames matching an \*r suffix denote \*r files;
+all others denote working files.
+Names are paired as explained in
+.BR ci (1).
+.PP
+The number of the revision to which the working file is compared
+may be attached to any of the options
+.BR \-n ,
+.BR \-q ,
+.BR \-r ,
+or
+.BR \-u .
+If no revision number is specified, then if the
+.B \-u
+option is given and the caller has one revision locked,
+.B rcsclean
+uses that revision; otherwise
+.B rcsclean
+uses the latest revision on the default branch, normally the root.
+.PP
+.B rcsclean
+is useful for
+.B clean
+targets in Makefiles.
+See also
+.BR rcsdiff (1),
+which prints out the differences,
+and
+.BR ci (1),
+which
+normally asks whether to check in a file
+if it was not changed.
+.SH OPTIONS
+.TP
+.BI \-k subst
+Use
+.I subst
+style keyword substitution when retrieving the revision for comparison.
+See
+.BR co (1)
+for details.
+.TP
+.BR \-n [\f2rev\fP]
+Do not actually remove any files or unlock any revisions.
+Using this option will tell you what
+.B rcsclean
+would do without actually doing it.
+.TP
+.BR \-q [\f2rev\fP]
+Do not log the actions taken on standard output.
+.TP
+.BR \-r [\f2rev\fP]
+This option has no effect other than specifying the revision for comparison.
+.TP
+.BR \-u [\f2rev\fP]
+Unlock the revision if it is locked and no difference is found.
+.TP
+.BI \-V n
+Emulate \*r version
+.IR n .
+See
+.BR co (1)
+for details.
+.TP
+.BI \-x "suffixes"
+Use
+.I suffixes
+to characterize \*r files.
+See
+.BR ci (1)
+for details.
+.SH EXAMPLES
+.LP
+.RS
+.ft 3
+rcsclean  *.c  *.h
+.ft
+.RE
+.LP
+removes all working files ending in
+.B .c
+or
+.B .h
+that were not changed
+since their checkout.
+.LP
+.RS
+.ft 3
+rcsclean
+.ft
+.RE
+.LP
+removes all working files in the current directory
+that were not changed since their checkout.
+.SH FILES
+.B rcsclean
+accesses files much as
+.BR ci (1)
+does.
+.SH ENVIRONMENT
+.TP
+.B \s-1RCSINIT\s0
+options prepended to the argument list, separated by spaces.
+A backslash escapes spaces within an option.
+The
+.B \s-1RCSINIT\s0
+options are prepended to the argument lists of most \*r commands.
+Useful
+.B \s-1RCSINIT\s0
+options include
+.BR \-q ,
+.BR \-V ,
+and
+.BR \-x .
+.SH DIAGNOSTICS
+The exit status is zero if and only if all operations were successful.
+Missing working files and \*r files are silently ignored.
+.SH IDENTIFICATION
+Author: Walter F. Tichy.
+.br
+Revision Number: \*(Rv; Release Date: \*(Dt.
+.br
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.br
+Copyright \(co 1990, 1991 by Paul Eggert.
+.SH "SEE ALSO"
+ci(1), co(1), ident(1), rcs(1), rcsdiff(1), rcsintro(1), rcsmerge(1), rlog(1),
+rcsfile(5)
+.br
+Walter F. Tichy,
+\*r\*-A System for Version Control,
+.I "Software\*-Practice & Experience"
+.BR 15 ,
+7 (July 1985), 637-654.
+.SH BUGS
+At least one
+.I file
+must be given in older Unix versions that
+do not provide the needed directory scanning operations.
+.br
diff --git a/usr/src/contrib/rcs-V5.6/man/rcsdiff.1 b/usr/src/contrib/rcs-V5.6/man/rcsdiff.1
new file mode 100644 (file)
index 0000000..b78bbdd
--- /dev/null
@@ -0,0 +1,152 @@
+.de Id
+.ds Rv \\$3
+.ds Dt \\$4
+..
+.Id $Id: rcsdiff.1,v 5.3 1991/04/21 12:00:46 eggert Exp $
+.ds r \&\s-1RCS\s0
+.if n .ds - \%--
+.if t .ds - \(em
+.TH RCSDIFF 1 \*(Dt GNU
+.SH NAME
+rcsdiff \- compare RCS revisions
+.SH SYNOPSIS
+.B rcsdiff
+[
+.BI \-k subst
+] [
+.B \-q
+] [
+.BI \-r rev1
+[
+.BI \-r rev2
+] ] [
+.BI \-V n
+] [
+.BI \-x suffixes
+] [
+.I "diff options"
+]
+.I "file .\|.\|."
+.SH DESCRIPTION
+.B rcsdiff
+runs
+.BR diff (1)
+to compare two revisions of each \*r file given.
+.PP
+Pathnames matching an \*r suffix denote \*r files;
+all others denote working files.
+Names are paired as explained in
+.BR ci (1).
+.PP
+The option
+.B \-q
+suppresses diagnostic output.
+Zero, one, or two revisions may be specified with
+.BR \-r .
+The option
+.BI \-k subst
+affects keyword substitution when extracting
+revisions, as described in
+.BR co (1);
+for example,
+.B "\-kk\ \-r1.1\ \-r1.2"
+ignores differences in keyword values when comparing revisions
+.B 1.1
+and
+.BR 1.2 .
+To avoid excess output from locker name substitution,
+.B \-kkvl
+is assumed if (1) at most one revision option is given,
+(2) no
+.B \-k
+option is given, (3)
+.B \-kkv
+is the default keyword substitution, and
+(4) the working file's mode would be produced by
+.BR "co\ \-l".
+See
+.BR co (1)
+for details
+about
+.B \-V
+and
+.BR \-x .
+Otherwise, all options of
+.BR diff (1)
+that apply to regular files are accepted, with the same meaning as for
+.BR diff .
+.PP
+If both
+.I rev1
+and
+.I rev2
+are omitted,
+.B 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.
+.PP
+If
+.I rev1
+is given, but
+.I rev2
+is omitted,
+.B rcsdiff
+compares revision
+.I rev1
+of the \*r file with
+the contents of the corresponding working file.
+.PP
+If both
+.I rev1
+and
+.I rev2
+are given,
+.B rcsdiff
+compares revisions
+.I rev1
+and
+.I rev2
+of the \*r file.
+.PP
+Both
+.I rev1
+and
+.I rev2
+may be given numerically or symbolically.
+.SH EXAMPLE
+The command
+.LP
+.B "        rcsdiff  f.c"
+.LP
+compares the latest revision on the default branch of the \*r file
+to the contents of the working file
+.BR f.c .
+.SH ENVIRONMENT
+.TP
+.B \s-1RCSINIT\s0
+options prepended to the argument list, separated by spaces.
+See
+.BR ci (1)
+for details.
+.SH DIAGNOSTICS
+Exit status is 0 for no differences during any comparison,
+1 for some differences, 2 for trouble.
+.SH IDENTIFICATION
+Author: Walter F. Tichy.
+.br
+Revision Number: \*(Rv; Release Date: \*(Dt.
+.br
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.br
+Copyright \(co 1990, 1991 by Paul Eggert.
+.SH "SEE ALSO"
+ci(1), co(1), diff(1), ident(1), rcs(1), rcsintro(1), rcsmerge(1), rlog(1)
+.br
+Walter F. Tichy,
+\*r\*-A System for Version Control,
+.I "Software\*-Practice & Experience"
+.BR 15 ,
+7 (July 1985), 637-654.
+.br
diff --git a/usr/src/contrib/rcs-V5.6/man/rcsfile.5 b/usr/src/contrib/rcs-V5.6/man/rcsfile.5
new file mode 100644 (file)
index 0000000..f3f79bd
--- /dev/null
@@ -0,0 +1,224 @@
+.de Id
+.ds Rv \\$3
+.ds Dt \\$4
+..
+.Id $Id: rcsfile.5,v 5.1 1991/08/19 03:13:55 eggert Exp $
+.ds r \s-1RCS\s0
+.if n .ds - \%--
+.if t .ds - \(em
+.TH RCSFILE 5 \*(Dt GNU
+.SH NAME
+rcsfile \- format of RCS file
+.SH DESCRIPTION
+An \*r file's
+contents are described by the grammar
+below.
+.PP
+The text is free format: space, backspace, tab, newline, vertical
+tab, form feed, and carriage return (collectively,
+.IR "white space")
+have no significance except in strings.
+However, an \*r file must end in a newline character.
+.PP
+Strings are enclosed by
+.BR @ .
+If a string contains a
+.BR @ ,
+it must be doubled;
+otherwise, strings may contain arbitrary binary data.
+.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;
+Terminal symbols are in
+.BR boldface ;
+nonterminal symbols are in
+.IR italics .
+.LP
+.nr x \w'\f3branches\fP'
+.nr y \w'{ \f3comment\fP'
+.if \nx<\ny .nr x \ny
+.nr y \w'\f3{ branch\fP'
+.if \nx<\ny .nr x \ny
+.ta \w'\f2deltatext\fP  'u +\w'::=  'u +\nxu+\w'  'u
+.fc ~
+.nf
+\f2rcstext\fP  ::=     \f2admin\fP {\f2delta\fP}* \f2desc\fP {\f2deltatext\fP}*
+.LP
+\f2admin\fP    ::=     \f3head\fP      {\f2num\fP}\f3;\fP
+               { \f3branch\fP  {\f2num\fP}\f3;\fP }
+               \f3access\fP    {\f2id\fP}*\f3;\fP
+               \f3symbols\fP   {\f2id\fP \f3:\fP \f2num\fP}*\f3;\fP
+               \f3locks\fP     {\f2id\fP \f3:\fP \f2num\fP}*\f3;\fP  {\f3strict  ;\fP}
+               { \f3comment\fP {\f2string\fP}\f3;\fP }
+               { \f3expand\fP  {\f2string\fP}\f3;\fP }
+               { \f2newphrase\fP }*
+.LP
+\f2delta\fP    ::=     \f2num\fP
+               \f3date\fP      \f2num\fP\f3;\fP
+               \f3author\fP    \f2id\fP\f3;\fP
+               \f3state\fP     {\f2id\fP}\f3;\fP
+               \f3branches\fP  {\f2num\fP}*\f3;\fP
+               \f3next\fP      {\f2num\fP}\f3;\fP
+               { \f2newphrase\fP }*
+.LP
+\f2desc\fP     ::=     \f3desc\fP      \f2string\fP
+.LP
+\f2deltatext\fP        ::=     \f2num\fP
+               \f3log\fP       \f2string\fP
+               { \f2newphrase\fP }*
+               \f3text\fP      \f2string\fP
+.LP
+\f2num\fP      ::=     {\f2digit\fP{\f3.\fP}}+
+.LP
+\f2digit\fP    ::=     \f30\fP | \f31\fP | .\|.\|. | \f39\fP
+.LP
+\f2id\fP       ::=     \f2letter\fP{\f2idchar\fP}*
+.LP
+\f2letter\fP   ::=     any letter
+.LP
+\f2idchar\fP   ::=     any visible graphic character except \f2special\fP
+.LP
+\f2special\fP  ::=     \f3$\fP | \f3,\fP | \f3.\fP | \f3:\fP | \f3;\fP | \f3@\fP
+.LP
+\f2string\fP   ::=     \f3@\fP{any character, with \f3@\fP doubled}*\f3@\fP
+.LP
+\f2newphrase\fP        ::=     \f2id\fP \f2word\fP* \f3;\fP
+.LP
+\f2word\fP     ::=     \f2id\fP | \f2num\fP | \f2string\fP | \f3:\fP
+.fi
+.PP
+Identifiers are case sensitive.  Keywords are in lower case only.
+The sets of keywords and identifiers may overlap.
+In most environments RCS uses the ISO 8859/1 encoding:
+letters are octal codes 101\-132, 141\-172, 300\-326, 330\-366 and 370-377,
+visible graphic characters are codes 041\-176 and 240\-377,
+and white space characters are codes 010\-015 and 040.
+.PP
+The
+.I newphrase
+productions in the grammar are reserved for future extensions
+to the format of \*r files.
+No
+.I newphrase
+will begin with any keyword already in use.
+.PP
+The
+.I 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
+.B next
+field in order of decreasing numbers.
+The
+.B head
+field in the
+.I admin
+node points to the head of that sequence (i.e., contains
+the highest pair).
+The
+.B branch
+node in the admin node indicates the default
+branch (or revision) for most \*r operations.
+If empty, the default
+branch is the highest branch on the trunk.
+.PP
+All
+.I delta
+nodes whose numbers consist of
+.RI 2 n
+fields
+.RI ( n \(\fP=2)
+(e.g., 3.1.1.1, 2.1.2.2, etc.)
+are linked as follows.
+All nodes whose first
+.RI 2 n \-1
+number fields are identical are linked through the
+.B next
+field in order of increasing numbers.
+For each such sequence,
+the
+.I delta
+node whose number is identical to the first
+.RI 2 n \-2
+number fields of the deltas on that sequence is called the branchpoint.
+The
+.B 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.
+.LP
+.nf
+.vs 12
+.ne 38
+Example:
+.if t .in +0.5i
+.cs 1 20
+.eo
+
+                           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  /
+                          \     /
+                           \   /
+                            \ /
+
+.ec
+.if t .in
+.cs 1
+.ce
+Fig. 1: A revision tree
+.vs
+.fi
+.PP
+.SH IDENTIFICATION
+.de VL
+\\$2
+..
+Author: Walter F. Tichy,
+Purdue University, West Lafayette, IN, 47907.
+.br
+Revision Number: \*(Rv; Release Date: \*(Dt.
+.br
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.br
+Copyright \(co 1990, 1991 by Paul Eggert.
+.SH SEE ALSO
+ci(1), co(1), ident(1), rcs(1), rcsdiff(1), rcsmerge(1), rlog(1),
+.br
+Walter F. Tichy,
+\*r\*-A System for Version Control,
+.I "Software\*-Practice & Experience"
+.BR 15 ,
+7 (July 1985), 637-654.
diff --git a/usr/src/contrib/rcs-V5.6/man/rcsfreeze.1 b/usr/src/contrib/rcs-V5.6/man/rcsfreeze.1
new file mode 100644 (file)
index 0000000..be669a9
--- /dev/null
@@ -0,0 +1,68 @@
+.de Id
+.ds Rv \\$3
+.ds Dt \\$4
+..
+.Id $Id: rcsfreeze.1,v 4.4 1990/11/13 15:43:42 hammer Exp $
+.ds r \s-1RCS\s0
+.TH RCSFREEZE 1 \*(Dt GNU
+.SH NAME
+rcsfreeze \- freeze a configuration of sources checked in under RCS
+.SH SYNOPSIS
+.B rcsfreeze
+.RI [ "name" ]
+.SH DESCRIPTION
+.B rcsfreeze
+assigns a symbolic revision
+number to a set of \*r files that form a valid configuration.
+.PP
+The idea is to run
+.B rcsfreeze
+each time a new version is checked
+in.  A unique symbolic name (\c
+.BI C_ number,
+where
+.I number
+is increased each time
+.B rcsfreeze
+is run) is then assigned to the most
+recent revision of each \*r file of the main trunk.
+.PP
+An optional
+.I name
+argument to
+.B rcsfreeze
+gives a symbolic name to the 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 \*r files.
+.PP
+A log message is requested from the user for future reference.
+.PP
+The shell script works only on all \*r files at one time.
+All changed files must be checked in already.
+Run
+.IR rcsclean (1)
+first and see whether any sources remain in the current directory.
+.SH FILES
+.TP
+.B RCS/.rcsfreeze.ver
+version number
+.TP
+.B RCS/.rcsfreeze.log
+log messages, most recent first
+.SH AUTHOR
+Stephan v. Bechtolsheim
+.SH "SEE ALSO"
+co(1), rcs(1), rcsclean(1), rlog(1)
+.SH BUGS
+.B rcsfreeze
+does not check whether any sources are checked out and modified.
+.PP
+Although both source file names and RCS file names are accepted,
+they are not paired as usual with RCS commands.
+.PP
+Error checking is rudimentary.
+.PP
+.B rcsfreeze
+is just an optional example shell script, and should not be taken too seriously.
+See \s-1CVS\s0 for a more complete solution.
diff --git a/usr/src/contrib/rcs-V5.6/man/rcsintro.1 b/usr/src/contrib/rcs-V5.6/man/rcsintro.1
new file mode 100644 (file)
index 0000000..a76caa0
--- /dev/null
@@ -0,0 +1,292 @@
+.de Id
+.ds Rv \\$3
+.ds Dt \\$4
+..
+.Id $Id: rcsintro.1,v 5.1 1991/04/21 12:00:46 eggert Exp $
+.ds r \&\s-1RCS\s0
+.if n .ds - \%--
+.if t .ds - \(em
+.am SS
+.LP
+..
+.TH RCSINTRO 1 \*(Dt GNU
+.SH NAME
+rcsintro \- introduction to RCS commands
+.SH DESCRIPTION
+The Revision Control System (\*r) manages multiple revisions of files.
+\*r automates the storing, retrieval, logging, identification, and merging
+of revisions.  \*r is useful for text that is revised frequently, for example
+programs, documentation, graphics, papers, and form letters.
+.PP
+The basic user interface is extremely simple.  The novice only needs
+to learn two commands:
+.BR ci (1)
+and
+.BR co (1).
+.BR ci ,
+short for \*(lqcheck in\*(rq, deposits the contents of a
+file into an archival file called an \*r file.  An \*r file
+contains all revisions of a particular file.
+.BR co ,
+short for \*(lqcheck out\*(rq, retrieves revisions from an \*r file.
+.SS "Functions of \*r"
+.IP \(bu
+Store and retrieve multiple revisions of text.  \*r 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
+Maintain a complete history of changes.
+\*r logs all changes automatically.
+Besides the text of each revision, \*r 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
+Resolve access conflicts.  When two or more programmers wish to
+modify the same revision, \*r alerts the programmers and prevents one
+modification from corrupting the other.
+.IP \(bu
+Maintain a tree of revisions.  \*r can maintain separate lines of development
+for each module.  It stores a tree structure that represents the
+ancestral relationships among revisions.
+.IP \(bu
+Merge revisions and resolve 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, \*r alerts the
+user about the overlapping changes.
+.IP \(bu
+Control releases and configurations.
+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
+Automatically identify 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
+Minimize secondary storage.  \*r needs little extra space for
+the revisions (only the differences).  If intermediate revisions are
+deleted, the corresponding deltas are compressed accordingly.
+.SS "Getting Started with \*r"
+Suppose you have a file
+.B f.c
+that you wish to put under control of \*r.
+If you have not already done so, make an \*r directory with the command
+.IP
+.B "mkdir  RCS"
+.LP
+Then invoke the check-in command
+.IP
+.B "ci  f.c"
+.LP
+This command creates an \*r file in the
+.B RCS
+directory,
+stores
+.B f.c
+into it as revision 1.1, and
+deletes
+.BR 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 in the \*r directory are called \*r files;
+the others are called working files.
+To get back the working file
+.B f.c
+in the previous example, use the check-out
+command
+.IP
+.B "co  f.c"
+.LP
+This command extracts the latest revision from the \*r file
+and writes
+it into
+.BR f.c .
+If you want to edit
+.BR f.c ,
+you must lock it as you check it out with the command
+.IP
+.B "co  \-l  f.c"
+.LP
+You can now edit
+.BR f.c .
+.PP
+Suppose after some editing you want to know what changes that you have made.
+The command
+.IP
+.B "rcsdiff  f.c"
+.LP
+tells you the difference between the most recently checked-in version
+and the working file.
+You can check the file back in by invoking
+.IP
+.B "ci  f.c"
+.LP
+This increments the revision number properly.
+.PP
+If
+.B ci
+complains with the message
+.IP
+.BI "ci error: no lock set by " "your name"
+.LP
+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
+.IP
+.B "rcs  \-l  f.c"
+.LP
+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
+.I "check-in"
+by anybody but the locker.
+.PP
+If your \*r 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 \*r file need not have a lock for check-in; all others
+still do.  Turning strict locking off and on is done with the commands
+.IP
+.BR "rcs  \-U  f.c" "     and     " "rcs  \-L  f.c"
+.LP
+If you don't want to clutter your working directory with \*r files, create
+a subdirectory called
+.B RCS
+in your working directory, and move all your \*r
+files there.  \*r 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 \*r and working files can be specified in three ways:
+(a) both are given, (b) only the working file is given, (c) only the
+\*r file is given.  Both \*r and working files may have arbitrary path prefixes;
+\*r commands pair them up intelligently.)
+.PP
+To avoid the deletion of the working file during check-in (in case you want to
+continue editing or compiling), invoke
+.IP
+.BR "ci  \-l  f.c" "     or     " "ci  \-u  f.c"
+.LP
+These commands check in
+.B 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 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).
+.PP
+You can give
+.B 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
+.IP
+.BR "ci  \-r2  f.c" "     or     " "ci  \-r2.1  f.c"
+.LP
+assigns the number 2.1 to the new revision.
+From then on,
+.B ci
+will number the subsequent revisions
+with 2.2, 2.3, etc.  The corresponding
+.B co
+commands
+.IP
+.BR "co  \-r2  f.c" "     and     " "co  \-r2.1  f.c"
+.PP
+retrieve the latest revision numbered
+.RI 2. x
+and the revision 2.1,
+respectively.
+.B co
+without a revision number selects
+the latest revision on the
+.IR trunk ,
+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
+.IP
+.B "ci  \-r1.3.1  f.c"
+.LP
+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
+.BR rcsfile (5).
+.SS "Automatic Identification"
+\*r can put special strings for identification into your source and object
+code.  To obtain such identification, place the marker
+.IP
+.B "$\&Id$"
+.LP
+into your text, for instance inside a comment.
+\*r will replace this marker with a string of the form
+.IP
+.BI $\&Id: "  filename  revision  date  time  author  state  " $
+.LP
+With such a marker on the first page of each module, you can
+always see with which revision you are working.
+\*r 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:
+.IP
+.ft 3
+static char rcsid[] = \&"$\&Id$\&";
+.ft
+.LP
+The command
+.B ident
+extracts such markers from any file, even object code
+and dumps.
+Thus,
+.B ident
+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
+.B $\&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
+.BR co (1)
+for
+details.
+.SH IDENTIFICATION
+Author: Walter F. Tichy.
+.br
+Revision Number: \*(Rv; Release Date: \*(Dt.
+.br
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.br
+Copyright \(co 1990, 1991 by Paul Eggert.
+.SH "SEE ALSO"
+ci(1), co(1), ident(1), rcs(1), rcsdiff(1), rcsintro(1), rcsmerge(1), rlog(1)
+.br
+Walter F. Tichy,
+\*r\*-A System for Version Control,
+.I "Software\*-Practice & Experience"
+.BR 15 ,
+7 (July 1985), 637-654.
+.br
diff --git a/usr/src/contrib/rcs-V5.6/man/rcsmerge.1 b/usr/src/contrib/rcs-V5.6/man/rcsmerge.1
new file mode 100644 (file)
index 0000000..82871b0
--- /dev/null
@@ -0,0 +1,140 @@
+.de Id
+.ds Rv \\$3
+.ds Dt \\$4
+..
+.Id $Id: rcsmerge.1,v 5.3 1991/08/19 03:13:55 eggert Exp $
+.ds r \&\s-1RCS\s0
+.if n .ds - \%--
+.if t .ds - \(em
+.TH RCSMERGE 1 \*(Dt GNU
+.SH NAME
+rcsmerge \- merge RCS revisions
+.SH SYNOPSIS
+.B rcsmerge
+.RI [ options ] " file"
+.SH DESCRIPTION
+.B rcsmerge
+incorporates the changes between two revisions
+of an \*r file into the corresponding working file.
+.PP
+Pathnames matching an \*r suffix denote \*r files;
+all others denote working files.
+Names are paired as explained in
+.BR ci (1).
+.PP
+At least one revision must be specified with one of the options
+described below, usually
+.BR \-r .
+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.
+.PP
+.B rcsmerge
+prints a warning if there are overlaps, and delimits
+the overlapping regions as explained in
+.BR merge (1).
+The command is useful for incorporating changes into a checked-out revision.
+.SH OPTIONS
+.TP
+.BI \-k subst
+Use
+.I subst
+style keyword substitution.
+See
+.BR co (1)
+for details.
+For example,
+.B "\-kk\ \-r1.1\ \-r1.2"
+ignores differences in keyword values when merging the changes from
+.B 1.1
+to
+.BR 1.2 .
+.TP
+.BR \-p [\f2rev\fP]
+Send the result to standard output instead of overwriting the working file.
+.TP
+.BR \-q [\f2rev\fP]
+Run quietly; do not print diagnostics.
+.TP
+.BR \-r [\f2rev\fP]
+Merge with respect to revision
+.IR rev .
+Here an empty
+.I rev
+stands for the latest revision on the default branch, normally the head.
+.TP
+.BI \-V n
+Emulate \*r version
+.IR n .
+See
+.BR co (1)
+for details.
+.TP
+.BI \-x "suffixes"
+Use
+.I suffixes
+to characterize \*r files.
+See
+.BR ci (1)
+for details.
+.SH EXAMPLES
+Suppose you have released revision 2.8 of
+.BR f.c .
+Assume
+furthermore that after you complete an unreleased revision 3.4, 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
+.LP
+.B "    rcsmerge  \-p  \-r2.8  \-r3.4  f.c  >f.merged.c"
+.PP
+Then examine
+.BR f.merged.c .
+Alternatively, if you want to save the updates to 2.8 in the \*r file,
+check them in as revision 2.8.1.1 and execute
+.BR "co \-j":
+.LP
+.B "    ci  \-r2.8.1.1  f.c"
+.br
+.B "    co  \-r3.4  \-j2.8:2.8.1.1  f.c"
+.PP
+As another example, the following command undoes the changes
+between revision 2.4 and 2.8 in your currently checked out revision
+in
+.BR f.c .
+.LP
+.B "    rcsmerge  \-r2.8  \-r2.4  f.c"
+.PP
+Note the order of the arguments, and that
+.B f.c
+will be
+overwritten.
+.SH ENVIRONMENT
+.TP
+.B \s-1RCSINIT\s0
+options prepended to the argument list, separated by spaces.
+See
+.BR ci (1)
+for details.
+.SH DIAGNOSTICS
+Exit status is 0 for no overlaps, 1 for some overlaps, 2 for trouble.
+.SH IDENTIFICATION
+Author: Walter F. Tichy.
+.br
+Revision Number: \*(Rv; Release Date: \*(Dt.
+.br
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.br
+Copyright \(co 1990, 1991 by Paul Eggert.
+.SH "SEE ALSO"
+ci(1), co(1), ident(1), merge(1), rcs(1), rcsdiff(1), rcsintro(1), rlog(1),
+rcsfile(5)
+.br
+Walter F. Tichy,
+\*r\*-A System for Version Control,
+.I "Software\*-Practice & Experience"
+.BR 15 ,
+7 (July 1985), 637-654.
+.br
diff --git a/usr/src/contrib/rcs-V5.6/man/rlog.1 b/usr/src/contrib/rcs-V5.6/man/rlog.1
new file mode 100644 (file)
index 0000000..fa627ff
--- /dev/null
@@ -0,0 +1,260 @@
+.de Id
+.ds Rv \\$3
+.ds Dt \\$4
+..
+.Id $Id: rlog.1,v 5.3 1991/08/22 06:50:48 eggert Exp $
+.ds g \&\s-1UTC\s0
+.ds r \&\s-1RCS\s0
+.if n .ds - \%--
+.if t .ds - \(em
+.TH RLOG 1 \*(Dt GNU
+.SH NAME
+rlog \- print log messages and other information about RCS files
+.SH SYNOPSIS
+.B rlog
+.RI [ " options " ] " file " .\|.\|.
+.SH DESCRIPTION
+.B rlog
+prints information about \*r files.
+.PP
+Pathnames matching an \*r suffix denote \*r files;
+all others denote working files.
+Names are paired as explained in
+.BR ci (1).
+.PP
+.B rlog
+prints the following information for each
+\*r file: \*r 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,
+.B 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 (\*g).
+Without options,
+.B rlog
+prints complete information.
+The options below restrict this output.
+.nr n \w'\f3\-V\fP\f2n\fP '+1n-1/1n
+.TP \nn
+.B \-L
+Ignore \*r files that have no locks set.
+This is convenient in combination with
+.BR \-h ,
+.BR \-l ,
+and
+.BR \-R .
+.TP
+.B \-R
+Print only the name of the \*r file.
+This is convenient for translating a
+working pathname into an \*r pathname.
+.TP
+.B \-h
+Print only the \*r pathname, working pathname, head,
+default branch, access list, locks,
+symbolic names, and suffix.
+.TP
+.B \-t
+Print the same as
+.BR \-h ,
+plus the descriptive text.
+.TP
+.B \-b
+Print information about the revisions on the default branch, normally
+the highest branch on the trunk.
+.TP
+.BI \-d "dates"
+Print information about revisions with a checkin date/time in the ranges given by
+the semicolon-separated list of
+.IR dates .
+A range of the form
+.IB d1 < d2
+or
+.IB d2 > d1
+selects the revisions that were deposited between
+.I d1
+and
+.I d2
+inclusive.
+A range of the form
+.BI < d
+or
+.IB d >
+selects
+all revisions dated
+.I d
+or earlier.
+A range of the form
+.IB d <
+or
+.BI > d
+selects
+all revisions dated
+.I d
+or later.
+A range of the form
+.I d
+selects the single, latest revision dated
+.I d
+or earlier.
+The date/time strings
+.IR d ,
+.IR d1 ,
+and
+.I d2
+are in the free format explained in
+.BR co (1).
+Quoting is normally necessary, especially for
+.B <
+and
+.BR > .
+Note that the separator is
+a semicolon.
+.TP
+.BR \-l [\f2lockers\fP]
+Print information about locked revisions only.
+In addition, if the comma-separated list
+.I lockers
+of login names is given,
+ignore all locks other than those held by the
+.IR lockers .
+For example,
+.B "rlog\ \-L\ \-R\ \-lwft\ RCS/*"
+prints the name of \*r files locked by the user
+.BR wft .
+.TP
+.BR \-r [\f2revisions\fP]
+prints information about revisions given in the comma-separated list
+.I revisions
+of revisions and ranges.
+A range
+.IB rev1 : rev2
+means revisions
+.I rev1
+to
+.I rev2
+on the same branch,
+.BI : rev
+means revisions from the beginning of the branch up to and including
+.IR rev ,
+and
+.IB rev :
+means revisions starting with
+.I rev
+to the end of the branch containing
+.IR rev .
+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
+.B .\&
+means the latest revision in that branch.
+A bare
+.B \-r
+with no
+.I revisions
+means the latest revision on the default branch, normally the trunk.
+.TP
+.BI \-s states
+prints information about revisions whose state attributes match one of the
+states given in the comma-separated list
+.IR states .
+.TP
+.BR \-w [\f2logins\fP]
+prints information about revisions checked in by users with
+login names appearing in the comma-separated list
+.IR logins .
+If
+.I logins
+is omitted, the user's login is assumed.
+.TP
+.BI \-V n
+Emulate \*r version
+.I n
+when generating logs.
+See
+.BR co (1)
+for more.
+.TP
+.BI \-x "suffixes"
+Use
+.I suffixes
+to characterize \*r files.
+See
+.BR ci (1)
+for details.
+.PP
+.B rlog
+prints the intersection of the revisions selected with
+the options
+.BR \-d ,
+.BR \-l ,
+.BR \-s ,
+and
+.BR \-w ,
+intersected
+with the union of the revisions selected by
+.B \-b
+and
+.BR \-r .
+.SH EXAMPLES
+.LP
+.nf
+.B "    rlog  \-L  \-R  RCS/*"
+.B "    rlog  \-L  \-h  RCS/*"
+.B "    rlog  \-L  \-l  RCS/*"
+.B "    rlog  RCS/*"
+.fi
+.LP
+The first command prints the names of all \*r files in the subdirectory
+.B 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.
+.SH ENVIRONMENT
+.TP
+.B \s-1RCSINIT\s0
+options prepended to the argument list, separated by spaces.
+See
+.BR ci (1)
+for details.
+.SH DIAGNOSTICS
+The exit status is zero if and only if all operations were successful.
+.SH IDENTIFICATION
+Author: Walter F. Tichy.
+.br
+Revision Number: \*(Rv; Release Date: \*(Dt.
+.br
+Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
+.br
+Copyright \(co 1990, 1991 by Paul Eggert.
+.SH "SEE ALSO"
+ci(1), co(1), ident(1), rcs(1), rcsdiff(1), rcsintro(1), rcsmerge(1),
+rcsfile(5)
+.br
+Walter F. Tichy,
+\*r\*-A System for Version Control,
+.I "Software\*-Practice & Experience"
+.BR 15 ,
+7 (July 1985), 637-654.
+.SH BUGS
+The separator for revision ranges in the
+.B \-r
+option used to be
+.B \-
+instead of
+.BR : ,
+but this leads to confusion when symbolic names contain
+.BR \- .
+For backwards compatibility
+.B "rlog \-r"
+still supports the old
+.B \-
+separator, but it warns about this obsolete use.
+.br
diff --git a/usr/src/contrib/rcs-V5.6/rcs_func.ms b/usr/src/contrib/rcs-V5.6/rcs_func.ms
new file mode 100644 (file)
index 0000000..9818086
--- /dev/null
@@ -0,0 +1,95 @@
+.SH
+Functions of RCS (Revision Control System)
+.PP
+RCS manages software libraries. It greatly increases programmer productivity
+by providing the following functions.
+.IP 1.
+RCS stores and retrieves multiple revisions of program and other text.
+Thus, one can maintain one or more releases while developing the next
+release, with a minimum of space overhead. Changes no longer destroy the
+original -- previous revisions remain accessible.
+.RS
+.IP a.
+Maintains each module as a tree of revisions.
+.IP b.
+Project libraries can
+be organized centrally, decentralized, or any way you like.
+.IP c.
+RCS works for any type of text: programs, documentation, memos, papers,
+graphics, VLSI layouts, form letters, etc.
+.RE
+.IP 2.
+RCS maintains a complete history of changes.
+Thus, one can find out what happened to a module easily
+and quickly, without having to compare source listings or
+having to track down colleagues.
+.RS
+.IP a.
+RCS performs automatic record keeping.
+.IP b.
+RCS logs all changes automatically.
+.IP c.
+RCS guarantees project continuity.
+.RE
+.IP 3.
+RCS manages multiple lines of development.
+.IP 4.
+RCS can merge multiple lines of development.
+Thus, when several parallel lines of development must be consolidated
+into one line, the merging of changes is automatic.
+.IP 5.
+RCS flags coding conflicts.
+If two or more lines of development modify the same section of code,
+RCS can alert programmers about overlapping changes.
+.IP 6.
+RCS resolves access conflicts.
+When two or more programmers wish to modify the same revision,
+RCS alerts the programmers and makes sure that one modification won't wipe
+out the other one.
+.IP 7.
+RCS provides high-level retrieval functions.
+Revisions can be retrieved according to ranges of revision numbers,
+symbolic names, dates, authors, and states.
+.IP 8.
+RCS provides release and configuration control.
+Revisions can be marked as released, stable, experimental, etc.
+Configurations of modules can be described simply and directly.
+.IP 9.
+RCS performs automatic identification of modules with name, revision
+number, creation time, author, etc.
+Thus, it is always possible to determine which revisions of which
+modules make up a given configuration.
+.IP 10.
+Provides high-level management visibility.
+Thus, it is easy to track the status of a software project.
+.RS
+.IP a.
+RCS provides a complete change history.
+.IP b.
+RCS records who did what when to which revision of which module.
+.RE
+.IP 11.
+RCS is fully compatible with existing software development tools.
+RCS is unobtrusive -- its interface to the file system is such that
+all your existing software tools can be used as before.
+.IP 12.
+RCS' basic user interface is extremely simple. The novice need to learn
+only two commands. Its more sophisticated features have been
+tuned towards advanced software development environments and the
+experienced software professional.
+.IP 13.
+RCS simplifies software distribution if customers
+maintain sources with RCS also. This technique assures proper
+identification of versions and configurations, and tracking of customer
+modifications. Customer modifications can be merged into distributed
+versions locally or by the development group.
+.IP 14.
+RCS needs little extra space for the revisions (only the differences).
+If intermediate revisions are deleted, the corresponding
+differences are compressed into the shortest possible form.
+.IP 15.
+RCS is implemented with reverse deltas. This means that
+the latest revision, which is the one that is accessed most often,
+is stored intact. All others are regenerated from the latest one
+by applying reverse deltas (backward differences). This
+results in fast access time for the revision needed most often.