BSD 4_3_Reno development
[unix-history] / usr / src / share / doc / ps1 / 13.rcs / man / co.1
CommitLineData
d6a5d192
C
1.TH CO 1 6/29/83 "Purdue University"
2.SH NAME
3co \- check out RCS revisions
4.SH SYNOPSIS
5.B co
6[ options ]
7file ...
8.SH DESCRIPTION
9.I Co
10retrieves revisions from RCS files.
11Each file name ending in `,v' is taken to be an RCS file.
12All other files
13are assumed to be working files.
14\fICo\fR retrieves a revision from each RCS file and stores it into
15the corresponding working file.
16.PP
17Pairs of RCS files and working files may be specified in 3 ways (see also the
18example section).
19.PP
201) Both the RCS file and the working file are given. The RCS file name is of
21the form \fIpath1/workfile\fR,v
22and the working file name is of the form
23\fIpath2/workfile\fR, where
24\fIpath1/\fR and
25\fIpath2/\fR are (possibly different or empty) paths and
26\fIworkfile\fR is a file name.
27.PP
282) Only the RCS file is given. Then the working file is created in the current
29directory and its name is derived from the name of the RCS file
30by removing \fIpath1/\fR and the suffix `,v'.
31.PP
323) Only the working file is given.
33Then the name of the RCS file is derived from the name of the working file
34by removing \fIpath2/\fR
35and appending the suffix `,v'.
36.PP
37If the RCS file is omitted or specified without a path, then \fIco\fR
38looks for the RCS file first in the directory ./RCS and then in the current
39directory.
40.PP
41Revisions of an RCS file may be checked out locked or unlocked. Locking a
42revision prevents overlapping updates. A revision checked out for reading or
43processing (e.g., compiling) need not be locked. A revision checked out
44for editing and later checkin must normally be locked. Locking a revision
45currently locked by another user fails. (A lock may be broken with
46the \fIrcs\fR (1) command.)
47\fICo\fR with locking requires the caller to be on the access list of
48the RCS file, unless he is the owner of the
49file or the superuser, or the access list is empty.
50\fICo\fR without locking is not subject to accesslist restrictions.
51.PP
52A revision is selected by number,
53checkin date/time,
54author, or state. If none of these options
55are specified, the latest revision
56on the trunk is retrieved.
57When the options
58are applied in combination, the latest revision
59that satisfies all of them is retrieved.
60The options for date/time, author, and state retrieve a revision on the \fIselected
61branch\fR. The selected branch is either derived from the revision number (if given),
62or is the highest branch on the trunk.
63A revision number may be attached
64to one of the options
65\fB-l\fR, \fB-p\fR, \fB-q\fR, or \fB-r\fR.
66.PP
67A \fIco\fR command applied to an RCS
68file with no revisions creates a zero-length file.
69\fICo\fR always performs keyword substitution (see below).
70.PP
71.TP 11
72.B \-l\fR[\fIrev\fR]
73locks the checked out revision for the caller.
74If omitted, the checked out revision is not locked.
75See option \fB-r\fR for handling of the revision number \fIrev\fR.
76.TP 11
77.B \-p\fR[\fIrev\fR]
78prints the retrieved revision on the std. output rather than storing it
79in the working file.
80This option is useful when \fIco\fR
81is part of a pipe.
82.TP 11
83.B \-q\fR[\fIrev\fR]
84quiet mode; diagnostics are not printed.
85.TP 11
86.BI \-d "date"
87retrieves the latest revision on the selected branch whose checkin date/time is less than or equal to \fIdate\fR.
88The date and time may be given in free format and are converted to local time.
89Examples of formats for \fIdate\fR:
90.nf
91
92\fI22-April-1982, 17:20-CDT,
932:25 AM, Dec. 29, 1983,
94Tue-PDT, 1981, 4pm Jul 21\fR \fR(free format),
95\fIFri, April 16 15:52:25 EST 1982 \fR(output of ctime).
96.fi
97
98Most fields in the date and time may be defaulted.
99\fICo\fR determines the defaults in the order year, month, day,
100hour, minute, and second (most to least significant). At least one of these
101fields must be provided. For omitted fields that are of higher significance
102than the highest provided field,
103the current values are assumed. For all other omitted fields,
104the lowest possible values are assumed.
105For example, the date "20, 10:30" defaults to
10610:30:00 of the 20th of the current month and current year.
107The date/time must be quoted if it contains spaces.
108.TP 11
109.B \-r\fR[\fIrev\fR]
110retrieves the latest revision whose number is less than or equal to \fIrev\fR.
111If \fIrev\fR indicates a branch rather than a revision,
112the latest revision on that branch is retrieved.
113\fIRev\fR is composed of one or more numeric or symbolic fields
114separated by `.'. The numeric equivalent of a symbolic field
115is specified with the \fB-n\fR option of the commands \fIci\fR and \fIrcs\fR.
116.TP 11
117.BI \-s "state"
118retrieves the latest revision on the selected branch whose state is set to \fIstate\fR.
119.TP 11
120.B \-w\fR[\fIlogin\fR]
121retrieves the latest revision on the selected branch which was checked in
122by the user with login name \fIlogin\fR. If the argument \fIlogin\fR is
123omitted, the caller's login is assumed.
124.TP 11
125.B \-j\fIjoinlist\fR
126generates a new revision which is the join of the revisions on \fIjoinlist\fR.
127\fIJoinlist\fR is a comma-separated list of pairs of the form
128\fIrev2:rev3\fR, where \fIrev2\fR and \fIrev3\fR are (symbolic or numeric)
129revision numbers.
130For the initial such pair, \fIrev1\fR denotes the revision selected
131by the options \fB-l\fR, ..., \fB-w\fR. For all other pairs, \fIrev1\fR
132denotes the revision generated by the previous pair. (Thus, the output
133of one join becomes the input to the next.)
134
135For each pair, \fIco\fR joins revisions \fIrev1\fR and \fIrev3\fR
136with respect to \fIrev2\fR.
137This means that all changes that transform
138\fIrev2\fR into \fIrev1\fR are applied to a copy of \fIrev3\fR.
139This is particularly useful if \fIrev1\fR
140and \fIrev3\fR are the ends of two branches that have \fIrev2\fR as a common
141ancestor. If \fIrev1\fR < \fIrev2\fR < \fIrev3\fR on the same branch,
142joining generates a new revision which is like \fIrev3\fR, but with all
143changes that lead from \fIrev1\fR to \fIrev2\fR undone.
144If changes from \fIrev2\fR to \fIrev1\fR overlap with changes from
145\fIrev2\fR to \fIrev3\fR, \fIco\fR prints a warning and includes the
146overlapping sections, delimited by the lines \fI<<<<<<<\ rev1,
147=======\fR, and \fI>>>>>>>\ rev3\fR.
148
149For the initial pair, \fIrev2\fR may be omitted. The default is the common
150ancestor.
151If any of the arguments indicate branches, the latest revisions
152on those branches are assumed. If the option \fB-l\fR is present,
153the initial \fIrev1\fR is locked.
154.SH "KEYWORD SUBSTITUTION"
155Strings of the form \fI$keyword$\fR and \fI$keyword:...$\fR embedded in
156the text are replaced
157with strings of the form \fI$keyword:\ value\ $\fR,
158where \fIkeyword\fR and \fIvalue\fR are pairs listed below.
159Keywords may be embedded in literal strings
160or comments to identify a revision.
161.PP
162Initially, the user enters strings of the form \fI$keyword$\fR.
163On checkout, \fIco\fR replaces these strings with strings of the form
164\fI$keyword:\ value\ $\fR. If a revision containing strings of the latter form
165is checked back in, the value fields will be replaced during the next
166checkout.
167Thus, the keyword values are automatically updated on checkout.
168.PP
169Keywords and their corresponding values:
170.TP 13
171$\&Author$
172The login name of the user who checked in the revision.
173. \.TP
174. \$\&Class$
175. \Prog, Def, Doc, or Test, depending on the class assigned to the file
176. \with the \fB-c\fR option of the \fIrcs\fR command.
177.TP
178$\&Date$
179The date and time the revision was checked in.
180.TP
181$\&Header$
182A standard header containing the RCS file name, the
183revision number, the date, the author, and the state.
184.TP
185$\&Locker$
186The login name of the user who locked the revision (empty if not locked).
187.TP
188$\&Log$
189The log message supplied during checkin, preceded by a header
190containing the RCS file name, the revision number, the author, and the date.
191Existing log messages are NOT replaced.
192Instead, the new log message is inserted after \fI$\&Log:...$\fR.
193This is useful for
194accumulating a complete change log in a source file.
195.TP
196$\&Revision$
197The revision number assigned to the revision.
198.TP
199$\&Source$
200The full pathname of the RCS file.
201.TP
202$\&State$
203The state assigned to the revision with \fIrcs -s\fR or \fIci -s\fR.
204.SH DIAGNOSTICS
205The RCS file name, the working file name,
206and the revision number retrieved are
207written to the diagnostic output.
208The exit status always refers to the last file checked out,
209and is 0 if the operation was successful, 1 otherwise.
210.SH EXAMPLES
211Suppose the current directory contains a subdirectory `RCS' with an RCS file
212`io.c,v'. Then all of the following commands retrieve the latest
213revision from `RCS/io.c,v' and store it into `io.c'.
214.nf
215.sp
216 co io.c; co RCS/io.c,v; co io.c,v;
217 co io.c RCS/io.c,v; co io.c io.c,v;
218 co RCS/io.c,v io.c; co io.c,v io.c;
219.fi
220.SH "FILE MODES"
221The working file inherits the read and execute permissions from the RCS
222file. In addition, the owner write permission is turned on, unless the file
223is checked out unlocked and locking is set to \fIstrict\fR (see
224\fIrcs\fR (1)).
225.PP
226If a file with the name of the working file exists already and has write
227permission, \fIco\fR aborts the checkout if \fB-q\fR is given, or asks
228whether to abort if \fB-q\fR is not given. If the existing working file is
229not writable, it is deleted before the checkout.
230.SH FILES
231The caller of the command must have write permission in the working
232directory, read permission for the RCS file, and either read permission
233(for reading) or read/write permission (for locking) in the directory which
234contains the RCS file.
235.PP
236A number of temporary files are created.
237A semaphore file is created in the directory of the RCS file
238to prevent simultaneous update.
239.SH IDENTIFICATION
240.de VL
241\\$2
242..
243Author: Walter F. Tichy,
244Purdue University, West Lafayette, IN, 47907.
245.sp 0
246Revision Number:
247.VL $Revision: 3.1 $
248; Release Date:
249.VL $Date: 83/04/04 15:53:40 $
250\&.
251.sp 0
252Copyright \(co 1982 by Walter F. Tichy.
253.SH SEE ALSO
254ci (1), ident(1), rcs (1), rcsdiff (1), rcsintro (1), rcsmerge (1), rlog (1), rcsfile (5), sccstorcs (8).
255.sp 0
256Walter F. Tichy, "Design, Implementation, and Evaluation of a Revision Control
257System," in \fIProceedings of the 6th International Conference on Software
258Engineering\fR, IEEE, Tokyo, Sept. 1982.
259.SH LIMITATIONS
260The option \fB-d\fR gets confused in some circumstances,
261and accepts no date before 1970.
262There is no way to suppress the expansion of keywords, except
263by writing them differently. In nroff and troff, this is done by embedding the
264null-character `\\&' into the keyword.
265.SH BUGS
266The option \fB-j\fR does not work for
267files that contain lines with a single `.'.