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