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