co man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

co(1)									 co(1)

       co - check out RCS revisions

       [options] file ...

       retrieves  revisions from RCS files.  Each file name ending in is taken
       to be an RCS file.  All other files are assumed to  be  working	files.
       retrieves  a  revision  from  each RCS file and stores it in the corre‐
       sponding working file (see also rcsintro(5)).

       Revisions of an RCS file can be checked out locked or unlocked.	 Lock‐
       ing  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 checked in must normally be
       locked.	Locking a revision currently locked by another user  fails  (a
       lock  can  be  broken  with  the command, but poses inherent risks when
       independent changes are being made simultaneously (see  rcs(1)).	  with
       locking	requires  the  caller to be on the access list of the RCS file
       unless: he is the owner of the file, a  user  with  appropriate	privi‐
       leges,  or the access list is empty.  without locking is not subject to
       access list restrictions.

       A revision is selected by number, check-in date/time, author, or state.
       If  none	 of  these  options  are specified, the latest revision on the
       trunk is retrieved.  When the options are applied in  combination,  the
       latest  revision	 that satisfies all of them is retrieved.  The options
       for date/time, author, and state retrieve a revision  on	 the  selected
       branch.	The selected branch is either derived from the revision number
       (if given), or is the highest branch on the trunk.  A  revision	number
       can be attached to the options or

       The  caller  of	the  command must have write permission in the working
       directory, read permission for the RCS file, and either read permission
       (for  reading)  or read/write permission (for locking) in the directory
       that contains the RCS file.

       The working file inherits the read and execute permissions from the RCS
       file.  In addition, the owner write permission is turned on, unless the
       file is checked out unlocked and locking is set to (see rcs(1)).

       If a file with the name of the working  file  exists  already  and  has
       write  permission, aborts the check out if is given, or asks whether to
       abort if is not given.  If the existing working file is	not  writable,
       it is deleted before the check out.

       A  number  of temporary files are created.  A semaphore file is created
       in the directory of the RCS file to prevent simultaneous update.

       A command applied to an RCS file with  no  revisions  creates  a	 zero-
       length file.  always performs keyword substitution (see below).

       Locks the checked out revision for the caller.
		      If omitted, the checked out revision is not locked.  See
		      option for handling of the revision number rev.

       Prints the retrieved revision on the standard output rather than	 stor‐
       ing it
		      in the working file.  This option is useful when is part
		      of a pipe.

       Quiet mode; diagnostics are not printed.

       Retrieves the latest revision on the selected branch
		      whose check in date/time is less than or equal to	 date.
		      The  date	 and  time may be given in free format and are
		      converted to local time.	Examples of formats for date:

			   Tue-PDT, 1981, 4pm Jul 21	    (free format)
			   Fri April 16 15:52:25 EST 1982   (output of ctime(3C))
			   4/21/86 10:30am		    (format: mm/dd/yy hh:mm:ss)

		      Most fields in the  date	and  time  can	be  defaulted.
		      determines  the  defaults in the order year, month, day,
		      hour, minute, and second (from most-  to	least-signifi‐
		      cant).   At  least one of these fields must be provided.
		      For omitted fields that are of higher significance  than
		      the  highest  provided  field,  the  current  values are
		      assumed.	For all other omitted fields, the lowest  pos‐
		      sible   values  are  assumed.   For  example,  the  date
		      defaults to 10:30:00 of the 20th of  the	current	 month
		      and  current year.  Date/time fields can be delimited by
		      spaces or commas.	 If spaces are used, the  string  must
		      be surrounded by double quotes.

		      For  2-digit year input (yy) without the presence of the
		      century field, the following interpretation is taken:

       Retrieves the latest revision whose number is less than or equal to
		      rev.  If rev indicates a branch rather than a  revision,
		      the latest revision on that branch is retrieved.	rev is
		      composed of one or more numeric or symbolic fields sepa‐
		      rated  by	 The numeric equivalent of a symbolic field is
		      specified with the and commands (see ci(1) and rcs(1)).

       Retrieves the latest revision
		      on the selected branch whose state is set to state.

       Retrieves the latest revision
		      on the selected branch that was checked in by  the  user
		      with  login  name login.	If the argument login is omit‐
		      ted, the caller's login is assumed.

       Generates a new revision that is the result
		      of the joining of the revisions on  joinlist.   joinlist
		      is  a  comma-separated  list  of pairs of the form where
		      rev2 and rev3 are (symbolic or  numeric)	revision  num‐
		      bers.   For  the initial pair, rev1 denotes the revision
		      selected by  the	options	 For  all  other  pairs,  rev1
		      denotes  the  revision  generated	 by the previous pair.
		      (Thus, the output of one join becomes the input  to  the

		      For  each	 pair,	joins  revisions  rev1	and  rev3 with
		      respect to rev2.	 This  means  that  all	 changes  that
		      transform	 rev2 into rev1 are applied to a copy of rev3.
		      This is particularly useful if rev1  and	rev3  are  the
		      ends  of	two branches that have rev2 as a common ances‐
		      tor.  If rev1 < rev2 < rev3 on the same branch,  joining
		      generates	 a  new	 revision that is similar to rev3, but
		      with all changes that lead from rev1 to rev2 undone.  If
		      changes from rev2 to rev1 overlap with changes from rev2
		      to rev3, prints a warning and includes  the  overlapping
		      sections, delimited as follows:


		      For  the initial pair, rev2 can be omitted.  The default
		      is the common ancestor.  If any of the  arguments	 indi‐
		      cate  branches,  the  latest revisions on those branches
		      are assumed.  If the option is present, the initial rev1
		      is locked.

   Keyword Substitution
       Strings	of the form and embedded in the text are replaced with strings
       of the form where keyword and value are pairs listed  below.   Keywords
       may be embedded in literal strings or comments to identify a revision.

       Initially,  the	user enters strings of the form On check out, replaces
       these strings with strings of the form If a revision containing strings
       of  the	latter	form is checked back in, the value fields are replaced
       during the next checkout.  Thus, the keyword values  are	 automatically
       updated on checkout.

       Keywords and their corresponding values:

       The login name of the user who checked in the revision.

       The date and time the revision was checked in.

       A standard header containing the
		      RCS  file	 name,	the  revision  number,	the  date, the
		      author, and the state.

       The login name of the user  who	locked	the  revision  (empty  if  not

       The log message supplied during checkin,
		      preceded	by  a header containing the RCS file name, the
		      revision number, the author, and the date.  Existing log
		      messages	are replaced.  Instead, the new log message is
		      inserted after This is useful for	 accumulating  a  com‐
		      plete change log in a source file.

       The revision number assigned to the revision.

       The full pathname of the
		      RCS file.

       The state assigned to the revision with

   Access Control Lists (ACLs)
       Optional	 ACL  entries  should  not  be added to RCS files because they
       might be deleted.

       The RCS file name, the working  file  name,  and	 the  revision	number
       retrieved are written to the diagnostic output.	The exit status always
       refers to the last file checked out, and is 0 if the operation was suc‐
       cessful, 1 if unsuccessful.

       Assume  the current directory contains a subdirectory named with an RCS
       file named Each of the following commands retrieves the latest revision
       from and stores it into

       Check out version 1.1 of RCS file

       Check out version 1.1 of RCS file to the standard output:

       Check out the version of file that existed on September 18, 1992:

       The  command  generates	the working file name by removing the from the
       end of the RCS file name.  If the given RCS file name is too  long  for
       the file system on which the RCS file should reside, terminates with an
       error message.

       There is no way to suppress the expansion of keywords, except by	 writ‐
       ing  them differently.  In and this is done by embedding the null-char‐
       acter into the keyword.

       The option gets confused in some circumstances,	and  accepts  no  date
       before 1970.

       The  option  does  not  work for files containing lines consisting of a

       RCS is designed to be used with text files only.	 Attempting to use RCS
       with non-text (binary) files results in data corruption.

       was developed by Walter F. Tichy.

       ci(1),  ident(1), rcs(1), rcsdiff(1), rcsmerge(1), rlog(1), rcsfile(4),
       acl(5), rcsintro(5).


List of man pages available for HP-UX

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]
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