rcs man page on Tru64

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
Tru64 logo
[printable version]

rcs(1)									rcs(1)

NAME
       rcs - change RCS file attributes

SYNOPSIS
       rcs [options] file...

OPTIONS
       Create  and initialize a new RCS file, but do not deposit any revision.
       If the RCS file has no path prefix, try to place it first into the sub‐
       directory  current  directory. If the RCS file already exists, print an
       error message.  Append the login names appearing in the comma-separated
       list logins to the access list of the RCS file.	Append the access list
       of oldfile to the access list of the RCS file.  Erase the  login	 names
       appearing  in  the  comma-separated list logins from the access list of
       the RCS file. If logins is omitted, erase the entire access list.   Set
       the  default  branch  to rev.  If rev is omitted, the default branch is
       reset to the (dynamically) highest branch on the trunk.	sets the  com‐
       ment  leader to string.	The comment leader is printed before every log
       message line generated  by  the	keyword	 $Log$	during	checkout  (see
       co(1)).	This  is  useful  for programming languages without multi-line
       comments. An initial ci , or an rcs -i without -c, guesses the  comment
       leader  from  the  suffix of the working file.  Set the default keyword
       substitution to subst. The effect of keyword substitution is  described
       in  co(1).   Giving  an explicit -k option to co, rcsdiff, and rcsmerge
       overrides this default.	Beware rcs -kv, because	 -kv  is  incompatible
       with  co -l. Use rcs -kkv to restore the normal default keyword substi‐
       tution.	Lock the revision with number rev.  If a branch is given, lock
       the  latest revision on that branch. If rev is omitted, lock the latest
       revision on the default branch.	Locking prevents overlapping  changes.
       A  lock	is removed with ci or rcs -u (see below).  Unlock the revision
       with number rev.	 If a branch is given, unlock the latest  revision  on
       that  branch.  If  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 by itself.  Set locking to strict. Strict lock‐
       ing  means that the owner of an RCS file is not exempt from locking for
       checkin.	 This option should be used for files that  are	 shared.   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  not  be
       used  for  files	 that are shared. Whether default locking is strict is
       determined by your system administrator, but  it	 is  normally  strict.
       Replace	revision  rev's	 log message with msg.	Associate the symbolic
       name name with the branch or revision rev. Delete the symbolic name  if
       both  :	and rev are omitted; otherwise, print an error message if name
       is already associated with another number. If rev is  symbolic,	it  is
       expanded	 before	 association. A rev consisting of a branch number fol‐
       lowed by a stands for the current latest revision in the	 branch.  A  :
       with an empty rev stands for the current latest revision on the default
       branch, normally the trunk. For example, rcs  -nname: RCS/*  associates
       name  with the current latest revision of all the named RCS files; this
       contrasts with rcs -nname:$ RCS/* which associates name with the	 revi‐
       sion  numbers extracted from keyword strings in the corresponding work‐
       ing files.  Act like -n, except override	 any  previous	assignment  of
       name.   deletes	(outdates)  the revisions given by range. A range con‐
       sisting of a single revision number means that revision. A  range  con‐
       sisting	of a branch number means the latest revision on that branch. A
       range of the form rev1:rev2 means revisions rev1 to rev2	 on  the  same
       branch,	:rev  means from the beginning of the branch containing rev up
       to and including rev, and rev: means from revision rev to  the  end  of
       the  branch  containing	rev.  None  of the outdated revisions may have
       branches or locks.  Run quietly; do not print diagnostics.  Run	inter‐
       actively,  even if the standard input is not a terminal.	 Set the state
       attribute of the revision rev to state. If  rev	is  a  branch  number,
       assume  the  latest  revision on that branch. If rev is omitted, assume
       the latest revision on the default branch.  Any identifier  is  accept‐
       able  for state. A useful set of states is Exp (for experimental), Stab
       (for stable), and Rel (for released). By default, ci(1) sets the	 state
       of  a revision to Exp.  Write descriptive text from the contents of the
       named file into the RCS file, deleting  the  existing  text.  The  file
       pathname	 may  not  begin  with -.  If file is omitted, obtain the text
       from standard input, terminated by end-of-file or by a line  containing
       by  itself.  Prompt  for	 the  text if interaction is possible; see -I.
       With -i, descriptive text is obtained even if -t is not	given.	 Write
       descriptive text from the string into the RCS file, deleting the exist‐
       ing text.  Emulate RCS version n. See co(1) for details.	 Use  suffixes
       to characterize RCS files. See ci(1) for details.

DESCRIPTION
       rcs  creates  new  RCS files or changes attributes of existing ones. An
       RCS file contains multiple revisions of text, an access list, a	change
       log,  descriptive  text,	 and some control attributes. For rcs to work,
       the caller's login name must be on  the	access	list,  except  if  the
       access  list is empty, the caller is the owner of the file or the supe‐
       ruser, or the -i option is present.

       Pathnames matching an RCS suffix denote RCS files;  all	others	denote
       working files. Names are paired as explained in ci(1). Revision numbers
       use the syntax described in ci(1).

COMPATIBILITY
       The -brev option generates an RCS file that cannot  be  parsed  by  RCS
       version 3 or earlier.

       The  -ksubst  options (except -kkv) generate an RCS file that cannot be
       parsed by RCS version 4 or earlier.

       Use rcs -Vn to make an RCS file acceptable to RCS version n by discard‐
       ing information that would confuse version n.

       RCS  version  5.5  and  earlier	does  not  support  the -x option, and
       requires a ,v suffix on an RCS pathname.

RESTRICTIONS
       The separator for revision ranges in the -o option used to be - instead
       of  :,  but this leads to confusion when symbolic names contain -.  For
       backwards compatibility rcs -o still supports the old - separator,  but
       it warns about this obsolete use.

       Symbolic	 names	need  not refer to existing revisions or branches. For
       example, the -o option does not remove symbolic names for the  outdated
       revisions; you must use -n to remove the names.

FILES
       rcs  accesses  files much as ci(1) does, except that it uses the effec‐
       tive 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 $ is specified.

ENVIRONMENT
       options prepended to the argument list, separated by spaces.  See ci(1)
       for details.

DIAGNOSTICS
       The RCS pathname and the revisions outdated are written to the diagnos‐
       tic output. The exit status is zero if and only if all operations  were
       successful.

IDENTIFICATION
       Author: Walter F. Tichy.
       Revision Number: 1.1.6.2; Release Date: 1993/10/07.
       Copyright � 1982, 1988, 1989 by Walter F. Tichy.
       Copyright � 1990, 1991 by Paul Eggert.

SEE ALSO
       co(1),  ci(1), ident(1), rcsdiff(1), rcsintro(1), rcsmerge(1), rlog(1),
       rcsfile(5)

       Walter F. Tichy, RCS--A System for Version Control,  Software--Practice
       & Experience 15, 7 (July 1985), 637-654.

									rcs(1)
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server Tru64

List of man pages available for Tru64

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net