![[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] / 43BSD / contrib / rcs / man|
Return to ci.1 CVS log | Up to [CSRG BSD Unix] / 43BSD / contrib / rcs / man |
1.1 root 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:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.