home *** CD-ROM | disk | FTP | other *** search
-
-
-
- CO(1) USER COMMANDS CO(1)
-
-
-
- NAME
- co - check out RCS revisions
-
- SYNOPSIS
- co [_o_p_t_i_o_n_s] _f_i_l_e ...
-
- DESCRIPTION
- co retrieves a revision from each RCS file and stores it
- into the corresponding working file.
-
- Pathnames matching an RCS suffix denote RCS files; all oth-
- ers denote working files. Names are paired as explained in
- ci(1).
-
- 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., com-
- piling) 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 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, -M, -p, -q, -r,
- or -u. The options -d (date), -s (state), and -w (author)
- retrieve from a single branch, the _s_e_l_e_c_t_e_d 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 key-
- word substitution (see below).
-
- OPTIONS
- -r[_r_e_v]
- retrieves the latest revision whose number is less than
- or equal to _r_e_v. If _r_e_v indicates a branch rather than
- a revision, the latest revision on that branch is
- retrieved. If _r_e_v is omitted, the latest revision on
- the default branch (see the -b option of rcs(1)) is
-
-
-
- GNU Last change: 1991/08/19 1
-
-
-
-
-
-
- CO(1) USER COMMANDS CO(1)
-
-
-
- retrieved. If _r_e_v is $, co determines the revision
- number from keyword values in the working file. Other-
- wise, 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[_r_e_v]
- same as -r, except that it also locks the retrieved
- revision for the caller.
-
- -u[_r_e_v]
- same as -r, except that it unlocks the retrieved revi-
- sion if it was locked by the caller. If _r_e_v is omit-
- ted, -u retrieves the revision locked by the caller, if
- there is one; otherwise, it retrieves the latest revi-
- sion on the default branch.
-
- -f[_r_e_v]
- 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.7 $ 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 values. See KEYWORD SUBSTITUTION below. For
- example, for the Revision keyword, generate the string
- $Revision$ instead of $Revision: 5.7 $. This option is
- useful to ignore differences due to keyword substitu-
- tion 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.7 $ 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.7 instead of $Revision: 5.7 $. This can help gen-
- erate files in programming languages where it is hard
-
-
-
- GNU Last change: 1991/08/19 2
-
-
-
-
-
-
- CO(1) USER COMMANDS CO(1)
-
-
-
- to strip keyword delimiters like $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 com-
- bined 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[_r_e_v]
- 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[_r_e_v]
- quiet mode; diagnostics are not printed.
-
- -I[_r_e_v]
- interactive mode; the user is prompted and questioned
- even if the standard input is not a terminal.
-
- -d_d_a_t_e
- retrieves the latest revision on the selected branch
- whose checkin date/time is less than or equal to _d_a_t_e.
- 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
- _d_a_t_es are equivalent if local time is January 11, 1990,
- 8pm Pacific Standard Time, eight hours west of Coordi-
- nated Universal Time (UTC):
-
- 8:00 pm lt
- 4:00 AM, Jan. 12, 1990 note: default is UTC
- 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 UTC. 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 pro-
- vided field, the time zone's current values are
- assumed. For all other omitted fields, the lowest pos-
- sible values are assumed. For example, the date 20,
- 10:30 defaults to 10:30:00 UTC of the 20th of the UTC
- time zone's current month and year. The date/time must
-
-
-
- GNU Last change: 1991/08/19 3
-
-
-
-
-
-
- CO(1) USER COMMANDS CO(1)
-
-
-
- be quoted if it contains spaces.
-
- -M[_r_e_v]
- 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 make(1).
-
- -s_s_t_a_t_e
- retrieves the latest revision on the selected branch
- whose state is set to _s_t_a_t_e.
-
- -w[_l_o_g_i_n]
- retrieves the latest revision on the selected branch
- which was checked in by the user with login name _l_o_g_i_n.
- If the argument _l_o_g_i_n is omitted, the caller's login is
- assumed.
-
- -j_j_o_i_n_l_i_s_t
- generates a new revision which is the join of the revi-
- sions on _j_o_i_n_l_i_s_t. This option is largely obsoleted by
- rcsmerge(1) but is retained for backwards compatibil-
- ity.
-
- The _j_o_i_n_l_i_s_t is a comma-separated list of pairs of the
- form _r_e_v_2:_r_e_v_3, where _r_e_v_2 and _r_e_v_3 are (symbolic or
- numeric) revision numbers. For the initial such pair,
- _r_e_v_1 denotes the revision selected by the above options
- -f, ..., -w. For all other pairs, _r_e_v_1 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 _r_e_v_1 and _r_e_v_3 with
- respect to _r_e_v_2. This means that all changes that
- transform _r_e_v_2 into _r_e_v_1 are applied to a copy of _r_e_v_3.
- This is particularly useful if _r_e_v_1 and _r_e_v_3 are the
- ends of two branches that have _r_e_v_2 as a common ances-
- tor. If _r_e_v_1<_r_e_v_2<_r_e_v_3 on the same branch, joining
- generates a new revision which is like _r_e_v_3, but with
- all changes that lead from _r_e_v_1 to _r_e_v_2 undone. If
- changes from _r_e_v_2 to _r_e_v_1 overlap with changes from
- _r_e_v_2 to _r_e_v_3, co reports overlaps as described in
- merge(1).
-
- For the initial pair, _r_e_v_2 may be omitted. The default
- is the common ancestor. If any of the arguments indi-
- cate branches, the latest revisions on those branches
- are assumed. The options -l and -u lock or unlock
- _r_e_v_1.
-
- -V_n 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
-
-
-
- GNU Last change: 1991/08/19 4
-
-
-
-
-
-
- CO(1) USER COMMANDS CO(1)
-
-
-
- version of RCS your correspondents 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 emu-
- lating 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 _y_y/_m_m/_d_d instead of _y_y_y_y/_m_m/_d_d and may also
- contain different white space in the substitution for
- $Log$.
-
- -x_s_u_f_f_i_x_e_s
- Use _s_u_f_f_i_x_e_s to characterize RCS files. See ci(1) for
- details.
-
- KEYWORD SUBSTITUTION
- Strings of the form $_k_e_y_w_o_r_d$ and $_k_e_y_w_o_r_d:...$ embedded in
- the text are replaced with strings of the form
- $_k_e_y_w_o_r_d:_v_a_l_u_e$ where _k_e_y_w_o_r_d and _v_a_l_u_e are pairs listed
- below. Keywords may be embedded in literal strings or com-
- ments to identify a revision.
-
- Initially, the user enters strings of the form $_k_e_y_w_o_r_d$.
- On checkout, co replaces these strings with strings of the
- form $_k_e_y_w_o_r_d:_v_a_l_u_e$. 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 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 (UTC) the revision was checked in.
-
- $Header$
- A standard header containing the full pathname of the
- RCS file, the revision number, the date (UTC), the
- author, the state, and the locker (if locked).
-
- $Id$ Same as $Header$, except that the RCS filename is
- without a path.
-
- $Locker$
- The login name of the user who locked the revision
- (empty if not locked).
-
-
-
- GNU Last change: 1991/08/19 5
-
-
-
-
-
-
- CO(1) USER COMMANDS CO(1)
-
-
-
- $Log$
- The log message supplied during checkin, preceded by a
- header containing the RCS filename, the revision
- number, the author, and the date (UTC). Existing log
- messages are _n_o_t replaced. Instead, the new log mes-
- sage 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 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.
-
- ENVIRONMENT
- RCSINIT
- options prepended to the argument list, separated by
- spaces. See ci(1) for details.
-
- DIAGNOSTICS
- The RCS 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 suc-
- cessful.
-
- IDENTIFICATION
- Author: Walter F. Tichy.
- Revision Number: 5.7; Release Date: 1991/08/19.
- Copyright c 1982, 1988, 1989 by Walter F. Tichy.
-
-
-
- GNU Last change: 1991/08/19 6
-
-
-
-
-
-
- CO(1) USER COMMANDS CO(1)
-
-
-
- Copyright c 1990, 1991 by Paul Eggert.
-
- SEE ALSO
- ci(1), ctime(3), date(1), ident(1), make(1), rcs(1),
- rcsdiff(1), rcsintro(1), rcsmerge(1), rlog(1), rcsfile(5)
- Walter F. Tichy, RCS--A System for Version Control,
- _S_o_f_t_w_a_r_e--_P_r_a_c_t_i_c_e & _E_x_p_e_r_i_e_n_c_e 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 Last change: 1991/08/19 7
-
-
-
-