![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to ci.1 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / rcs / man|
Return to ci.1 CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / rcs / man |
1.1 root 1: .TH CI 1L "" "Purdue University"
2: .SH NAME
3: ci \- check in RCS revisions
4: .SH SYNOPSIS
5: .B ci
6: [ options ]
7: file ...
8: .SH DESCRIPTION
9: .I Ci
10: stores new revisions into RCS files.
11: Each file name ending in `,v' is taken to be an RCS file, all others
12: are assumed to be working files containing new revisions.
13: \fICi\fR deposits the contents of each working file
14: into the corresponding RCS file.
15: If only a working file is given, \fIci\fR tries to find the corresponding
16: RCS file in the directory ./RCS and then in the current directory.
17: For more details, see the file naming section below.
18: .PP
19: For \fIci\fR to work, the caller's login must be on the access list,
20: except if the access list is empty or the caller is the superuser or the
21: owner of the file.
22: To append a new revision to an existing branch, the tip revision on
23: that branch must be locked by the caller. Otherwise, only a
24: new branch can be created. This restriction is not enforced
25: for the owner of the file, unless locking is set to \fIstrict\fR
26: (see
27: .IR rcs (1L)).
28: A lock held by someone else may be broken with the \fIrcs\fR command.
29: .PP
30: Normally, \fIci\fR checks whether the revision to be deposited is different
31: from the preceding one. If it is not different, \fIci\fR
32: either aborts the deposit (if
33: .B \-q
34: is given) or asks whether to abort
35: (if
36: .B \-q
37: is omitted). A deposit can be forced with the
38: .B \-f
39: option.
40: .PP
41: For each revision deposited,
42: .I ci
43: prompts for a log message.
44: The log message should summarize the change and must be terminated with
45: a line containing a single `.' or a control-D.
46: If several files are checked in, \fIci\fR asks whether to reuse the
47: previous log message.
48: If the standard input is not a terminal, \fIci\fR suppresses the prompt
49: and uses the same log message for all files.
50: See also \fB\-m\fR.
51: .PP
52: The number of the deposited revision can be given by any of the options
53: \fB\-r\fR, \fB\-f\fR, \fB\-k\fR, \fB\-l\fR, \fB\-u\fR, or \fB\-q\fR.
54: .PP
55: If the RCS file does not exist, \fIci\fR creates it and
56: deposits the contents of the working file as the initial revision
57: (default number: 1.1).
58: The access list is initialized to empty.
59: Instead of the log message, \fIci\fR requests descriptive text (see
60: \fB\-t\fR below).
61: .TP 10
62: .BR \-r [\fIrev\fR]
63: assigns the revision number \fIrev\fR
64: to the checked-in revision, releases the corresponding lock, and
65: deletes the working file. This is the default.
66: \fIRev\fR may be symbolic, numeric, or mixed.
67:
68: If \fIrev\fR is a revision number, it must be higher than the latest
69: one on the branch to which \fIrev\fR belongs, or must start a new branch.
70:
71: If \fIrev\fR is a branch rather than a revision number,
72: the new revision is appended to that branch. The level number is obtained
73: by incrementing the tip revision number of that branch.
74: If \fIrev\fR indicates a non-existing branch,
75: that branch is created with the initial revision numbered
76: .IR rev .1.
77:
78: .ne 8
79: If \fIrev\fR is omitted, \fIci\fR tries to derive the new revision number from
80: the caller's last lock. If the caller has locked the tip revision of a branch,
81: the new revision is appended to that branch. The new revision number is obtained
82: by incrementing the tip revision number.
83: If the caller locked a non-tip revision, a new branch is started at
84: that revision by incrementing the highest branch number at that revision.
85: The default initial branch and level numbers are 1.
86:
87: If \fIrev\fR is omitted and the caller has no lock, but he is the owner
88: of the file and locking
89: is not set to \fIstrict\fR, then the revision is appended to the
90: default branch (normally the trunk; see the
91: .B \-b
92: option of
93: .IR rcs (1L)).
94:
95: Exception: On the trunk, revisions can be appended to the end, but
96: not inserted.
97: .TP 10
98: .BR \-f [\fIrev\fR]
99: forces a deposit; the new revision is deposited even it is not different
100: from the preceding one.
101: .TP 10
102: .BR \-k [\fIrev\fR]
103: searches the working file for keyword values to determine its revision number,
104: creation date, state, and author (see \fIco\fR(1)), and assigns these
105: values to the deposited revision, rather than computing them locally.
106: It also generates a default login message noting the login of the caller
107: and the actual checkin date.
108: This option is useful for software distribution. A revision that is sent to
109: several sites should be checked in with the \fB\-k\fR option at these sites to
110: preserve the original number, date, author, and state.
111: The extracted keyword values and the default log message may be overridden
112: with the options \fB\-r\fR, \fB\-d\fR, \fB\-s\fR, \fB\-w\fR, and \fB\-m\fR.
113: .TP 10
114: .BR \-l [\fIrev\fR]
115: works like \fB\-r\fR, except it performs an additional \fIco \fB\-l\fR for the
116: deposited revision. Thus, the deposited revision is immediately
117: checked out again and locked.
118: This is useful for saving a revision although one wants to continue
119: editing it after the checkin.
120: .TP 10
121: .BR \-u [\fIrev\fR]
122: works like \fB\-l\fR, except that the deposited revision is not locked.
123: This is useful if one wants to process (e.g., compile) the revision
124: immediately after checkin.
125: .TP 10
126: .BR \-q [\fIrev\fR]
127: quiet mode; diagnostic output is not printed.
128: A revision that is not different from the preceding one is not deposited,
129: unless \fB\-f\fR is given.
130: .TP 10
131: .BI \-d "date"
132: uses \fIdate\fR for the checkin date and time.
133: \fIDate\fR may be specified in free format as explained in \fIco\fR(1).
134: Useful for lying about the checkin date, and for
135: .B \-k
136: if no date is available.
137: .TP 10
138: .BI \-m "msg"
139: uses the string \fImsg\fR as the log message for all revisions checked in.
140: .TP 10
141: .BI \-n "name"
142: assigns the symbolic name \fIname\fR to the number of the checked-in revision.
143: \fICi\fR prints an error message if \fIname\fR is already assigned to another
144: number.
145: .TP 10
146: .BI \-N "name"
147: same as \fB\-n\fR, except that it overrides a previous assignment of \fIname\fR.
148: .TP
149: .BI \-s "state"
150: sets the state of the checked-in revision to the identifier \fIstate\fR.
151: The default is \fIExp\fR.
152: .TP
153: .BR \-t [\fItxtfile\fR]
154: writes descriptive text into the RCS file (deletes the existing text).
155: If \fItxtfile\fR is omitted,
156: \fIci\fR prompts the user for text supplied from the standard input,
157: terminated with a line containing a single `.' or control-D.
158: Otherwise, the descriptive text is copied from the file \fItxtfile\fR.
159: During initialization, descriptive text is requested
160: even if \fB\-t\fR is not given.
161: The prompt is suppressed if standard input is not a terminal.
162: .TP
163: .BI \-w "login"
164: uses \fIlogin\fR for the author field of the deposited revision.
165: Useful for lying about the author, and for
166: .B \-k
167: if no author is available.
168: .SH "FILE NAMING"
169: Pairs of RCS files and working files may be specified in 3 ways (see also the
170: example section of \fIco\fR(1)).
171: .PP
172: 1) Both the RCS file and the working file are given. The RCS file name is of
173: the form \fIpath1/workfile,v\fR
174: and the working file name is of the form
175: \fIpath2/workfile\fR, where
176: \fIpath1/\fR and
177: \fIpath2/\fR are (possibly different or empty) paths and
178: \fIworkfile\fR is a file name.
179: .PP
180: 2) Only the RCS file is given.
181: Then the working file is assumed to be in the current
182: directory and its name is derived from the name of the RCS file
183: by removing \fIpath1/\fR and the suffix \fI,v\fR.
184: .PP
185: 3) Only the working file is given.
186: Then \fIci\fR looks for an RCS file of the form
187: \fIpath2/RCS/workfile,v\fR or \fIpath2/workfile,v\fR (in this order).
188: .PP
189: If the RCS file is specified without a path in 1) and 2), then \fIci\fR
190: looks for the RCS file first in the directory ./RCS and then in the current
191: directory.
192: .SH "FILE MODES"
193: An RCS file created by \fIci\fR inherits the read and execute permissions
194: from the working file. If the RCS file exists already, \fIci\fR
195: preserves its read and execute permissions.
196: \fICi\fR always turns off all write permissions of RCS files.
197: .SH FILES
198: The caller of the command
199: must have read/write permission for the directories containing
200: the RCS file and the working file, and read permission for the RCS file itself.
201: A number of temporary files are created.
202: A semaphore file is created in the directory containing the RCS file.
203: \fICi\fR always creates a new RCS file and unlinks the old one.
204: This strategy makes links to RCS files useless.
205: .SH DIAGNOSTICS
206: For each revision,
207: \fIci\fR prints the RCS file, the working file, and the number
208: of both the deposited and the preceding revision.
209: The exit status always refers to the last file checked in,
210: and is 0 if the operation was successful, 1 otherwise.
211: .SH IDENTIFICATION
212: .de VL
213: \\$2
214: ..
215: Author: Walter F. Tichy,
216: Purdue University, West Lafayette, IN, 47907.
217: .sp 0
218: Revision Number:
219: .VL $Revision: 1.3 $
220: ; Release Date:
221: .VL $Date: 89/05/02 11:12:08 $
222: \&.
223: .sp 0
224: Copyright \(co 1982, 1988, 1989 by Walter F. Tichy.
225: .SH SEE ALSO
226: co(1L), ident(1L), rcs(1L), rcsdiff(1L), rcsintro(1L), rcsmerge(1L), rlog(1L),
227: rcsfile(5L)
228: .sp 0
229: Walter F. Tichy, "Design, Implementation, and Evaluation of a Revision Control
230: System," in \fIProceedings of the 6th International Conference on Software
231: Engineering\fR, IEEE, Tokyo, Sept. 1982.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.