1CI(1) General Commands Manual CI(1)
2
6 ci - check in RCS revisions
7
9 ci [ options ] file ...
10
12 Ci stores new revisions into RCS files. Each file name ending in `,v'
13 is taken to be an RCS file, all others are assumed to be working files
14 containing new revisions. Ci deposits the contents of each working
15 file into the corresponding RCS file.
16 Pairs of RCS files and working files may be specified in 3 ways (see
18 also the example section of co (1)).
19 1) Both the RCS file and the working file are given. The RCS file name
21 is of the form path1/workfile,v and the working file name is of the
22 form path2/workfile, where path1/ and path2/ are (possibly different or
23 empty) paths and workfile is a file name.
24 2) Only the RCS file is given. Then the working file is assumed to be
26 in the current directory and its name is derived from the name of the
27 RCS file by removing path1/ and the suffix `,v'.
28 3) Only the working file is given. Then the name of the RCS file is
30 derived from the name of the working file by removing path2/ and
31 appending the suffix `,v'.
32 If the RCS file is omitted or specified without a path, then ci looks
34 for the RCS file first in the directory ./RCS and then in the current
35 directory.
36 For ci to work, the caller's login must be on the access list, except
38 if the access list is empty or the caller is the superuser or the owner
39 of the file. To append a new revision to an existing branch, the tip
40 revision on that branch must be locked by the caller. Otherwise, only a
41 new branch can be created. This restriction is not enforced for the
42 owner of the file, unless locking is set to strict (see rcs (1)). A
43 lock held by someone else may be broken with the rcs command.
44 Normally, ci checks whether the revision to be deposited is different
46 from the preceding one. If it is not different, ci either aborts the
47 deposit (if -q is given) or asks whether to abort (if -q is omitted). A
48 deposit can be forced with the -f option.
49 For each revision deposited, ci prompts for a log message. The log
51 message should summarize the change and must be terminated with a line
52 containing a single `.' or a control-D. If several files are checked
53 in, ci asks whether to reuse the previous log message. If the std.
54 input is not a terminal, ci suppresses the prompt and uses the same log
55 message for all files. See also -m.
56 The number of the deposited revision can be given by any of the options
58 -r, -f, -k, -l, -u, or -q (see -r).
59 If the RCS file does not exist, ci creates it and deposits the contents
61 of the working file as the initial revision (default number: 1.1). The
62 access list is initialized to empty. Instead of the log message, ci
63 requests descriptive text (see -t below).
64 -r[rev] assigns the revision number rev to the checked-in revision,
66 releases the corresponding lock, and deletes the working
67 file. This is also the default.
68 If rev is omitted, ci derives the new revision number from
70 the caller's last lock. If the caller has locked the tip
71 revision of a branch, the new revision is appended to that
72 branch. The new revision number is obtained by incrementing
73 the tip revision number. If the caller locked a non-tip
74 revision, a new branch is started at that revision by incre‐
75 menting the highest branch number at that revision. The
76 default initial branch and level numbers are 1. If the call‐
77 er holds no lock, but he is the owner of the file and locking
78 is not set to strict, then the revision is appended to the
79 trunk.
80 If rev indicates a revision number, it must be higher than
82 the latest one on the branch to which rev belongs, or must
83 start a new branch.
84 If rev indicates a branch instead of a revision, the new
86 revision is appended to that branch. The level number is
87 obtained by incrementing the tip revision number of that
88 branch. If rev indicates a non-existing branch, that branch
89 is created with the initial revision numbered rev.1.
90 Exception: On the trunk, revisions can be appended to the
92 end, but not inserted.
93 -f[rev] forces a deposit; the new revision is deposited even it is
95 not different from the preceding one.
96 -k[rev] searches the working file for keyword values to determine its
98 revision number, creation date, author, and state (see co
99 (1)), and assigns these values to the deposited revision,
100 rather than computing them locally. A revision number given
101 by a command option overrides the number in the working file.
102 This option is useful for software distribution. A revision
103 that is sent to several sites should be checked in with the
104 -k option at these sites to preserve its original number,
105 date, author, and state.
106 -l[rev] works like -r, except it performs an additional co -l for the
108 deposited revision. Thus, the deposited revision is immedi‐
109 ately checked out again and locked. This is useful for sav‐
110 ing a revision although one wants to continue editing it
111 after the checkin.
112 -u[rev] works like -l, except that the deposited revision is not
114 locked. This is useful if one wants to process (e.g., com‐
115 pile) the revision immediately after checkin.
116 -q[rev] quiet mode; diagnostic output is not printed. A revision
118 that is not different from the preceding one is not
119 deposited, unless -f is given.
120 -mmsg uses the string msg as the log message for all revisions
122 checked in.
123 -nname assigns the symbolic name name to the number of the checked-
125 in revision. Ci prints an error message if name is already
126 assigned to another number.
127 -Nname same as -n, except that it overrides a previous assignment of
129 name.
130 -sstate sets the state of the checked-in revision to the identifier
132 state. The default is Exp.
133 -t[txtfile]
135 writes descriptive text into the RCS file (deletes the exist‐
136 ing text). If txtfile is omitted, ci prompts the user for
137 text supplied from the std. input, terminated with a line
138 containing a single `.' or control-D. Otherwise, the
139 descriptive text is copied from the file txtfile. During
140 initialization, descriptive text is requested even if -t is
141 not given. The prompt is suppressed if std. input is not a
142 terminal.
143
145 For each revision, ci prints the RCS file, the working file, and the
146 number of both the deposited and the preceding revision. The exit sta‐
147 tus always refers to the last file checked in, and is 0 if the opera‐
148 tion was successful, 1 otherwise.
149
151 An RCS file created by ci inherits the read and execute permissions
152 from the working file. If the RCS file exists already, ci preserves its
153 read and execute permissions. Ci always turns off all write permis‐
154 sions of RCS files.
155
157 The caller of the command must have read/write permission for the
158 directories containing the RCS file and the working file, and read per‐
159 mission for the RCS file itself. A number of temporary files are cre‐
160 ated. A semaphore file is created in the directory containing the RCS
161 file. Ci always creates a new RCS file and unlinks the old one. This
162 strategy makes links to RCS files useless.
163
165 Author: Walter F. Tichy, Purdue University, West Lafayette, IN, 47907.
166 Revision Number: 3.1 ; Release Date: 83/04/04 .
167 Copyright © 1982 by Walter F. Tichy.
168
170 co (1), ident(1), rcs (1), rcsdiff (1), rcsintro (1), rcsmerge (1),
171 rlog (1), rcsfile (5), sccstorcs (8).
172 Walter F. Tichy, "Design, Implementation, and Evaluation of a Revision
173 Control System," in Proceedings of the 6th International Conference on
174 Software Engineering, IEEE, Tokyo, Sept. 1982.
175
177Purdue University 6/29/83 CI(1)