co man page on Xenix

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

CO(1)									  CO(1)

NAME
       co - check out RCS revisions

SYNOPSIS
       co [options] file ...

DESCRIPTION
       co retrieves a revision from each RCS file and stores it into the corre-
       sponding working file.  Each file name ending in ,v is taken  to	 be  an
       RCS  file;  all	other files are assumed to be working files.  If only a
       working file is given, co tries to find the corresponding  RCS  file  in
       the  directory  ./RCS  and  then	 in  the  current  directory.  For more
       details, see FILE NAMING below.

       Revisions of an RCS file may be checked out locked or unlocked.	Locking
       a  revision  prevents  overlapping  updates.  A revision checked out for
       reading or processing (e.g., compiling) need not be locked.  A  revision
       checked	out  for  editing  and	later  checkin must normally be locked.
       Checkout with locking fails if the revision to be checked  out  is  cur-
       rently  locked  by  another  user.  (A lock may be broken with rcs(1).)
       Checkout with locking also requires the caller to be on the access  list
       of the RCS file, unless he is the owner of the file or the superuser, or
       the access list is empty.  Checkout without locking is  not  subject  to
       accesslist restrictions, and is not affected by the presence of locks.

       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,  co	 retrieves  the	 latest	 revision that satisfies all of
       them.  If none of the selection options is specified, co	 retrieves  the
       latest  revision	 on  the default branch (normally the trunk, see the -b
       option of rcs(1)).  A revision or branch number may be attached	to  any
       of the options -f, -I, -l, -p, -q, -r, or -u.  The options -d (date), -s
       (state), and -w (author) retrieve from a	 single	 branch,  the  selected
       branch,	which is either specified by one of -f, ..., -u, or the default
       branch.

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

OPTIONS
       -r[rev]
	      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.  If rev is  omitted,
	      the  latest  revision on the default branch (see the -b option of
	      rcs(1)) is retrieved.  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 -n option of
	      the commands ci(1) and rcs(1).

       -l[rev]
	      same  as -r, except that it also locks the retrieved revision for
	      the caller.

       -u[rev]
	      same as -r, except that it unlocks the retrieved revision	 if  it
	      was  locked  by  the caller.  If rev is omitted, -u retrieves the
	      latest revision locked by the caller; if no such lock exists,  it
	      retrieves the latest revision on the default branch.

       -f[rev]
	      forces  the overwriting of the working file; useful in connection
	      with -q.	See also FILE MODES below.

       -kkv   Generate keyword strings using the default form, e.g.  $Revision:
	      5.4  $  for the Revision keyword.	 A locker's name is inserted in
	      the value of the Header, Id, and Locker keyword strings only as a
	      file  is	being  locked,	i.e.  by  ci -l and co -l.  This is the
	      default.

       -kkvl  Like -kkv, except that a locker's name is always inserted if  the
	      given revision is currently locked.

       -kk    Generate	only  keyword names in keyword strings; omit their val-
	      ues.  See KEYWORD SUBSTITUTION below.  For example, for the Revi-
	      sion  keyword,  generate	the string $Revision$ instead of $Revi-
	      sion: 5.4 $.  This option is useful to ignore differences due  to
	      keyword  substitution  when  comparing  different	 revisions of a
	      file.

       -ko    Generate the old keyword string, present in the working file just
	      before it was checked in.	 For example, for the Revision keyword,
	      generate the string $Revision: 1.1 $ instead of $Revision: 5.4  $
	      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.

       -kv    Generate only keyword values for keyword strings.	  For  example,
	      for  the	Revision  keyword,  generate  the string 5.4 instead of
	      $Revision: 5.4 $.	 This can help generate	 files	in  programming
	      languages	 where	it  is	hard  to  strip keyword delimiters like
	      $Revision: $ from a string.  However, further  keyword  substitu-
	      tion  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 -l, and the
	      owner write permission of the working file is turned off; to edit
	      the file later, check it out again without -kv.

       -p[rev]
	      prints  the retrieved revision on the standard output rather than
	      storing it in the working file.  This option is useful when co is
	      part of a pipe.

       -q[rev]
	      quiet mode; diagnostics are not printed.

       -I[rev]
	      interactive mode; the user is prompted and questioned even if the
	      standard input is not a terminal.

       -ddate retrieves the  latest  revision  on  the	selected  branch  whose
	      checkin  date/time  is  less than or equal to date.  The date and
	      time may be given in free format.	 The time zone	LT  stands  for
	      local  time;  other  common  time zone names are understood.  For
	      example, the following dates are equivalent if local time is Jan-
	      uary  11,	 1990,	8pm  Pacific Standard Time (eight hours west of
	      GMT):

		     8:00 pm lt
		     4:00 AM, Jan. 12, 1990	      note: default is GMT
		     1990/01/12 04:00:00	      RCS date format
		     Thu Jan 11 20:00:00 1990 LT      output of ctime(3) + LT
		     Thu Jan 11 20:00:00 PST 1990     output of date(1)
		     Fri Jan 12 04:00:00 GMT 1990
		     Thu, 11 Jan 1990 20:00:00 -0800
		     Fri-JST, 1990, 1pm Jan 12
		     12-January-1990, 04:00-WET

	      Most fields in the date and time may be defaulted.   The	default
	      time zone is GMT.	 The other defaults are determined in the order
	      year, month, day, hour, minute, and second (most to least signif-
	      icant).	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 20, 10:30 defaults to 10:30:00 GMT of the
	      20th of  the  GMT	 time  zone's  current	month  and  year.   The
	      date/time must be quoted if it contains spaces.

       -sstate
	      retrieves	 the latest revision on the selected branch whose state
	      is set to state.

       -w[login]
	      retrieves the latest revision on the selected  branch  which  was
	      checked  in  by  the user with login name login.	If the argument
	      login is omitted, the caller's login is assumed.

       -jjoinlist
	      generates a new revision which is the join of  the  revisions  on
	      joinlist.	 This option is largely obsoleted by rcsmerge(1) but is
	      retained for backwards compatibility.

	      The joinlist is a comma-separated	 list  of  pairs  of  the  form
	      rev2:rev3, where rev2 and rev3 are (symbolic or numeric) revision
	      numbers.	For the initial such pair, rev1	 denotes  the  revision
	      selected	by the above options -f, ..., -w.  For all other pairs,
	      rev1 denotes the revision generated by the previous pair.	 (Thus,
	      the output of one join becomes the input to the next.)

	      For  each	 pair, co 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  ancestor.	  If rev1<rev2<rev3 on the same branch, joining
	      generates a new revision which is like 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, co prints a  warning  and
	      includes	 the  overlapping  sections,  delimited	 by  the  lines
	      <<<<<<< rev1, =======, and >>>>>>> rev3.

	      For the initial pair, 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  -l
	      and -u lock or unlock rev1.

       -Vn    Emulate  RCS  version  n, where n may be 3, 4, or 5.  This may be
	      useful when interchanging RCS files with others who  are	running
	      older  versions  of RCS.	To see which version of RCS your corre-
	      spondents are running, have them invoke rlog on an RCS  file;  if
	      none  of the first few lines of output contain the string branch:
	      it is version 3; if the dates' years have just two digits, it  is
	      version  4;  otherwise,  it  is version 5.  An RCS file generated
	      while emulating version 3 will lose its default branch.	An  RCS
	      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 yy/mm/dd instead of yyyy/mm/dd and may also contain	differ-
	      ent white space in the substitution for $Log$.

KEYWORD SUBSTITUTION
       Strings of the form $keyword$ and $keyword:...$ embedded in the text are
       replaced with strings of the  form  $keyword:value$  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 $keyword$.  On  checkout,
       co  replaces these strings with strings of the form $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 key-
       word values are automatically updated on checkout.  This automatic  sub-
       stitution can be modified by the -k options.

       Keywords and their corresponding values:

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

       $Date$ The date and time (GMT) the revision was checked in.

       $Header$
	      A	 standard  header containing the full pathname of the RCS file,
	      the revision number, the date (GMT), the author, the  state,  and
	      the locker (if locked).

       $Id$   Same  as	$Header$,  except  that	 the RCS file name is without a
	      path.

       $Locker$
	      The login name of the user who locked the revision (empty if  not
	      locked).

       $Log$  The  log	message	 supplied  during checkin, preceded by a header
	      containing the RCS file name, the revision  number,  the	author,
	      and  the	date  (GMT).   Existing	 log messages are not replaced.
	      Instead, the new log message is inserted after  $Log:...$.   This
	      is  useful  for  accumulating  a	complete change log in a source
	      file.

       $RCSfile$
	      The name of the RCS file without a path.

       $Revision$
	      The revision number assigned to the revision.

       $Source$
	      The full pathname of the RCS file.

       $State$
	      The state assigned to the revision with the -s option  of	 rcs(1)
	      or ci(1).

FILE NAMING
       Pairs of RCS files and working files may be specified in three ways (see
       also the example section).

       1) Both the RCS file and the working file are given.  The RCS file  name
       is of the form path1/workfile,v and the working file name is of the form
       path2/workfile where path1/ and path2/ are (possibly different or empty)
       paths and workfile is a file name.

       2)  Only the RCS file is given.	Then the working file is created in the
       current directory and its name is derived from the name of the RCS  file
       by removing path1/ and the suffix ,v.

       3) Only the working file is given.  Then co looks for an RCS file of the
       form path2/RCS/workfile,v or path2/workfile,v (in this order).

       If the RCS file is specified without a path in 1) and 2), then co  looks
       for  the	 RCS  file first in the directory ./RCS and then in the current
       directory.

EXAMPLES
       Suppose the current directory contains a subdirectory RCS  with	an  RCS
       file  io.c,v.   Then  all  of the following commands retrieve the latest
       revision from RCS/io.c,v and store it into io.c.

	      co  io.c;	   co  RCS/io.c,v;   co	 io.c,v;
	      co  io.c	RCS/io.c,v;    co  io.c	 io.c,v;

	      co  RCS/io.c,v  io.c;    co  io.c,v  io.c;

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

       If a file with the name of the working file exists already and has write
       permission, co aborts the checkout, asking beforehand if	 possible.   If
       the  existing  working  file is not writable or -f is given, the working
       file is deleted without asking.

FILES
       co accesses files much as ci(1) does, except that it does  not  need  to
       read the working file.

DIAGNOSTICS
       The  RCS	 file  name,  the  working  file  name, and the revision number
       retrieved are written to the diagnostic output.	The exit status is zero
       if and only if all operations were successful.

IDENTIFICATION
       Author: Walter F. Tichy.
       Revision Number: 5.4; Release Date: 1990/12/04.
       Copyright (C) 1982, 1988, 1989 by Walter F. Tichy.
       Copyright (C) 1990 by Paul Eggert.

SEE ALSO
       ci(1),  ctime(3),  date(1),  ident(1),  rcs(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.

LIMITS
       Links to the RCS and working files are not preserved.

       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 \& into the keyword.

BUGS
       The  -d option sometimes gets confused, and accepts no date before 1970.

GNU				   1990/12/04				      6
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server Xenix

List of man pages available for Xenix

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