co man page on NeXTSTEP

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


CO(1)									 CO(1)

NAME
       co - check out RCS revisions

SYNOPSIS
       co [ options ] file ...

DESCRIPTION
       Co  retrieves  revisions from RCS files.	 Each file name ending in `,v'
       is taken to be an RCS file.  All other files are assumed to be  working
       files.	Co  retrieves a revision from each RCS file and stores it into
       the corresponding working file.

       Pairs of RCS files and working files may be specified in	 3  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 the name of the	 RCS  file  is
       derived	from  the  name	 of  the  working  file by removing path2/ and
       appending the suffix `,v'.

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

       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.
       Locking a revision currently locked by another user fails. (A lock  may
       be  broken  with	 the  rcs  (1) command.)  Co with locking 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.  Co without
       locking is not subject to accesslist restrictions.

       A revision is selected by number, checkin 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
       may be attached to one of the options -l, -p, -q, or -r.

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

       -l[rev]	  locks the checked out revision for the caller.  If  omitted,
		  the  checked	out revision is not locked.  See option -r for
		  handling of the revision number rev.

       -p[rev]	  prints the retrieved revision on the std. 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.

       -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 and  are	 converted  to
		  local time.  Examples of formats for date:

		  22-April-1982, 17:20-CDT,
		  2:25 AM, Dec. 29, 1983,
		  Tue-PDT, 1981, 4pm Jul 21	    (free format),
		  Fri, April 16 15:52:25 EST 1982 (output of ctime).

		  Most	fields	in  the	 date  and  time may be defaulted.  Co
		  determines the defaults in the order year, month, day, hour,
		  minute, and second (most to least significant). At least one
		  of these fields must be provided. For	 omitted  fields  that
		  are  of higher significance than the highest provided field,
		  the current  values  are  assumed.  For  all	other  omitted
		  fields,   the	 lowest	 possible  values  are	assumed.   For
		  example, the date "20, 10:30" defaults to  10:30:00  of  the
		  20th	of  the current month and current year.	 The date/time
		  must be quoted if it contains spaces.

       -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.
		  Rev  is  composed  of one or more numeric or symbolic fields
		  separated by `.'. The numeric equivalent of a symbolic field
		  is specified with the -n option of the commands ci and rcs.

       -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.	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 options	-l,  ...,  -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. If the option -l is present, the  initial  rev1  is
		  locked.

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
       keyword values are automatically updated on checkout.

       Keywords and their corresponding values:

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

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

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

       $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.  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.

       $Revision$   The revision number assigned to the revision.

       $Source$	    The full pathname of the RCS file.

       $State$	    The state assigned to the revision with rcs -s or ci -s.

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

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 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  if  -q  is  given,  or  asks
       whether	to  abort  if -q is not given. If the existing working file is
       not writable, it is deleted before the checkout.

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

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

IDENTIFICATION
       Author: Walter F. Tichy, Purdue University, West Lafayette, IN, 47907.
       Revision Number: 3.1 ; Release Date: 83/04/04 .
       Copyright © 1982 by Walter F. Tichy.

SEE ALSO
       ci (1), ident(1), rcs (1), rcsdiff (1),	rcsintro  (1),	rcsmerge  (1),
       rlog (1), rcsfile (5), sccstorcs (8).
       Walter  F. Tichy, "Design, Implementation, and Evaluation of a Revision
       Control System," in Proceedings of the 6th International Conference  on
       Software Engineering, IEEE, Tokyo, Sept. 1982.

LIMITATIONS
       The  option -d gets confused in some circumstances, and accepts no date
       before 1970.  There is no way to suppress the  expansion	 of  keywords,
       except by writing them differently. In nroff and troff, this is done by
       embedding the null-character `\&' into the keyword.

BUGS
       The option -j does not work for files that contain lines with a	single
       `.'.

Purdue University		    6/29/83				 CO(1)
[top]

List of man pages available for NeXTSTEP

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