BSD 4_3_Reno development
[unix-history] / usr / src / share / doc / ps1 / 13.rcs / man / ci.1
CommitLineData
d6a5d192
C
1.TH CI 1 6/29/83 "Purdue University"
2.SH NAME
3ci \- check in RCS revisions
4.SH SYNOPSIS
5.B ci
6[ options ]
7file ...
8.SH DESCRIPTION
9.I Ci
10stores new revisions into RCS files.
11Each file name ending in `,v' is taken to be an RCS file, all others
12are assumed to be working files containing new revisions.
13\fICi\fR deposits the contents of each working file
14into the corresponding RCS file.
15.PP
16Pairs of RCS files and working files may be specified in 3 ways (see also the
17example section of \fIco\fR (1)).
18.PP
191) Both the RCS file and the working file are given. The RCS file name is of
20the form \fIpath1/workfile\fR,v
21and the working file name is of the form
22\fIpath2/workfile\fR, where
23\fIpath1/\fR and
24\fIpath2/\fR are (possibly different or empty) paths and
25\fIworkfile\fR is a file name.
26.PP
272) Only the RCS file is given.
28Then the working file is assumed to be 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 \fIci\fR
38looks for the RCS file first in the directory ./RCS and then in the current
39directory.
40.PP
41For \fIci\fR to work, the caller's login must be on the access list,
42except if the access list is empty or the caller is the superuser or the
43owner of the file.
44To append a new revision to an existing branch, the tip revision on
45that branch must be locked by the caller. Otherwise, only a
46new branch can be created. This restriction is not enforced
47for the owner of the file, unless locking is set to \fIstrict\fR
48(see \fIrcs\fR (1)).
49A lock held by someone else may be broken with the \fIrcs\fR command.
50.PP
51Normally, \fIci\fR checks whether the revision to be deposited is different
52from the preceding one. If it is not different, \fIci\fR
53either aborts the deposit (if \fB-q\fR is given) or asks whether to abort
54(if \fB-q\fR is omitted). A deposit can be forced with the \fB-f\fR option.
55.PP
56For each revision deposited, \fIci\fR prompts for a log message.
57The log message should summarize the change and must be terminated with
58a line containing a single `.' or a control-D.
59If several files are checked in, \fIci\fR asks whether to reuse the
60previous log message.
61If the std. input is not a terminal, \fIci\fR suppresses the prompt
62and uses the same log message for all files.
63See also \fB-m\fR.
64.PP
65The number of the deposited revision can be given by any of the options
66\fB-r\fR, \fB-f\fR, \fB-k\fR, \fB-l\fR, \fB-u\fR, or \fB-q\fR (see \fB-r\fR).
67.PP
68If the RCS file does not exist, \fIci\fR creates it and
69deposits the contents of the working file as the initial revision
70(default number: 1.1).
71The access list is initialized to empty.
72Instead of the log message, \fIci\fR requests descriptive text (see
73\fB-t\fR below).
74.TP 10
75.B \-r\fR[\fIrev\fR]
76assigns the revision number \fIrev\fR
77to the checked-in revision, releases the corresponding lock, and
78deletes the working file. This is also the default.
79
80If \fIrev\fR is omitted, \fIci\fR derives the new revision number from
81the caller's last lock. If the caller has locked the tip revision of a branch,
82the new revision is appended to that branch. The new revision number is obtained
83by incrementing the tip revision number.
84If the caller locked a non-tip revision, a new branch is started at
85that revision by incrementing the highest branch number at that revision.
86The default initial branch and level numbers are 1.
87If the caller holds no lock, but he is the owner of the file and locking
88is not set to \fIstrict\fR, then the revision is appended to the trunk.
89
90If \fIrev\fR indicates a revision number, it must be higher than the latest
91one on the branch to which \fIrev\fR belongs, or must start a new branch.
92
93If \fIrev\fR indicates a branch instead of a revision,
94the new revision is appended to that branch. The level number is obtained
95by incrementing the tip revision number of that branch.
96If \fIrev\fR indicates a non-existing branch,
97that branch is created with the initial revision numbered \fIrev.1\fR.
98
99Exception: On the trunk, revisions can be appended to the end, but
100not inserted.
101.TP 10
102.B \-f\fR[\fIrev\fR]
103forces a deposit; the new revision is deposited even it is not different
104from the preceding one.
105.TP 10
106.B \-k\fR[\fIrev\fR]
107searches the working file for keyword values to determine its revision number,
108creation date, author, and state (see \fIco\fR (1)), and assigns these
109values to the deposited revision, rather than computing them locally.
110A revision number given by a command option overrides the number
111in the working file.
112This option is useful for software distribution. A revision that is sent to
113several sites should be checked in with the \fB-k\fR option at these sites to
114preserve its original number, date, author, and state.
115.TP 10
116.B \-l\fR[\fIrev\fR]
117works like \fB-r\fR, except it performs an additional \fIco -l\fR for the
118deposited revision. Thus, the deposited revision is immediately
119checked out again and locked.
120This is useful for saving a revision although one wants to continue
121editing it after the checkin.
122.TP 10
123.B \-u\fR[\fIrev\fR]
124works like \fB-l\fR, except that the deposited revision is not locked.
125This is useful if one wants to process (e.g., compile) the revision
126immediately after checkin.
127.TP 10
128.B \-q\fR[\fIrev\fR]
129quiet mode; diagnostic output is not printed.
130A revision that is not different from the preceding one is not deposited,
131unless \fB-f\fR is given.
132.TP 10
133.BI \-m "msg"
134uses the string \fImsg\fR as the log message for all revisions checked in.
135.TP 10
136.BI \-n "name"
137assigns the symbolic name \fIname\fR to the number of the checked-in revision.
138\fICi\fR prints an error message if \fIname\fR is already assigned to another
139number.
140.TP 10
141.BI \-N "name"
142same as \fB-n\fR, except that it overrides a previous assignment of \fIname\fR.
143.TP
144.BI \-s "state"
145sets the state of the checked-in revision to the identifier \fIstate\fR.
146The default is \fIExp\fR.
147.TP
148.B \-t\fR[\fItxtfile\fR]
149writes descriptive text into the RCS file (deletes the existing text).
150If \fItxtfile\fR is omitted,
151\fIci\fR prompts the user for text supplied from the std. input,
152terminated with a line containing a single `.' or control-D.
153Otherwise, the descriptive text is copied from the file \fItxtfile\fR.
154During initialization, descriptive text is requested
155even if \fB-t\fR is not given.
156The prompt is suppressed if std. input is not a terminal.
157.SH DIAGNOSTICS
158For each revision,
159\fIci\fR prints the RCS file, the working file, and the number
160of both the deposited and the preceding revision.
161The exit status always refers to the last file checked in,
162and is 0 if the operation was successful, 1 otherwise.
163.SH "FILE MODES"
164An RCS file created by \fIci\fR inherits the read and execute permissions
165from the working file. If the RCS file exists already, \fIci\fR
166preserves its read and execute permissions.
167\fICi\fR always turns off all write permissions of RCS files.
168.SH FILES
169The caller of the command
170must have read/write permission for the directories containing
171the RCS file and the working file, and read permission for the RCS file itself.
172A number of temporary files are created.
173A semaphore file is created in the directory containing the RCS file.
174\fICi\fR always creates a new RCS file and unlinks the old one.
175This strategy makes links to RCS files useless.
176.SH IDENTIFICATION
177.de VL
178\\$2
179..
180Author: Walter F. Tichy,
181Purdue University, West Lafayette, IN, 47907.
182.sp 0
183Revision Number:
184.VL $Revision: 3.1 $
185; Release Date:
186.VL $Date: 83/04/04 15:52:35 $
187\&.
188.sp 0
189Copyright \(co 1982 by Walter F. Tichy.
190.SH SEE ALSO
191co (1), ident(1), rcs (1), rcsdiff (1), rcsintro (1), rcsmerge (1), rlog (1), rcsfile (5), sccstorcs (8).
192.sp 0
193Walter F. Tichy, "Design, Implementation, and Evaluation of a Revision Control
194System," in \fIProceedings of the 6th International Conference on Software
195Engineering\fR, IEEE, Tokyo, Sept. 1982.
196.SH BUGS
197