1 2 3 4RCSINTRO(1L) 1983 RCSINTRO(1L) 5 6 7NNAAMMEE 8 rcsintro - introduction to RCS commands 9 10DDEESSCCRRIIPPTTIIOONN 11 The Revision Control System (RCS) manages multiple 12 revisions of text files. RCS automates the storing, 13 retrieval, logging, identification, and merging of 14 revisions. RCS is useful for text that is revised 15 frequently, for example programs, documentation, graphics, 16 papers, form letters, etc. 17 18 The basic user interface is extremely simple. The novice 19 only needs to learn two commands: _c_i(1L) and _c_o(1L). _C_i, 20 short for "check in", deposits the contents of a text file 21 into an archival file called an RCS file. An RCS file 22 contains all revisions of a particular text file. _C_o, 23 short for "check out", retrieves revisions from an RCS 24 file. 25 26 FFuunnccttiioonnss ooff RRCCSS 27 28 29 o Storage and retrieval of multiple revisions of 30 text. RCS saves all old revisions in a space 31 efficient way. Changes no longer destroy the 32 original, because the previous revisions remain 33 accessible. Revisions can be retrieved according to 34 ranges of revision numbers, symbolic names, dates, 35 authors, and states. 36 37 o Maintenance of a complete history of changes. RCS 38 logs all changes automatically. Besides the text 39 of each revision, RCS stores the author, the date 40 and time of check-in, and a log message summarizing 41 the change. The logging makes it easy to find out 42 what happened to a module, without having to 43 compare source listings or having to track down 44 colleagues. 45 46 o Resolution of access conflicts. When two or more 47 programmers wish to modify the same revision, RCS 48 alerts the programmers and prevents one 49 modification from corrupting the other. 50 51 o Maintenance of a tree of Revisions. RCS can 52 maintain separate lines of development for each 53 module. It stores a tree structure that represents 54 the ancestral relationships among revisions. 55 56 o Merging of revisions and resolution of conflicts. 57 Two separate lines of development of a module can 58 be coalesced by merging. If the revisions to be 59 merged affect the same sections of code, RCS alerts 60 the user about the overlapping changes. 61 62 63 6411, May 1 65 66 67 68 69 70RCSINTRO(1L) 1983 RCSINTRO(1L) 71 72 73 o Release and configuration control. Revisions can be 74 assigned symbolic names and marked as released, 75 stable, experimental, etc. With these facilities, 76 configurations of modules can be described simply 77 and directly. 78 79 o Automatic identification of each revision with 80 name, revision number, creation time, author, etc. 81 The identification is like a stamp that can be 82 embedded at an appropriate place in the text of a 83 revision. The identification makes it simple to 84 determine which revisions of which modules make up 85 a given configuration. 86 87 o Minimization of secondary storage. RCS needs little 88 extra space for the revisions (only the 89 differences). If intermediate revisions are 90 deleted, the corresponding deltas are compressed 91 accordingly. 92 93 94 GGeettttiinngg SSttaarrtteedd wwiitthh RRCCSS 95 96 Suppose you have a file f.c that you wish to put under 97 control of RCS. Invoke the check-in command 98 99 ccii ff..cc 100 101 This command creates the RCS file f.c,v, stores f.c into 102 it as revision 1.1, and deletes f.c. It also asks you for 103 a description. The description should be a synopsis of the 104 contents of the file. All later check-in commands will ask 105 you for a log entry, which should summarize the changes 106 that you made. 107 108 Files ending in ,v are called RCS files (`v' stands for 109 `versions'), the others are called working files. To get 110 back the working file f.c in the previous example, use the 111 check-out command 112 113 ccoo ff..cc 114 115 This command extracts the latest revision from f.c,v and 116 writes it into f.c. You can now edit f.c and check it back 117 in by invoking 118 119 ccii ff..cc 120 121 _C_i increments the revision number properly. If _c_i 122 complains with the message 123 124 ci error: no lock set by <your login> 125 126 then your system administrator has decided to create all 127 128 129 13011, May 2 131 132 133 134 135 136RCSINTRO(1L) 1983 RCSINTRO(1L) 137 138 139 RCS files with the locking attribute set to `strict'. In 140 this case, you should have locked the revision during the 141 previous check-out. Your last check-out should have been 142 143 ccoo --ll ff..cc 144 145 Of course, it is too late now to do the check-out with 146 locking, because you probably modified f.c already, and a 147 second check-out would overwrite your modifications. 148 Instead, invoke 149 150 rrccss --ll ff..cc 151 152 This command will lock the latest revision for you, unless 153 somebody else got ahead of you already. In this case, 154 you'll have to negotiate with that person. 155 156 Locking assures that you, and only you, can check in the 157 next update, and avoids nasty problems if several people 158 work on the same file. Even if a revision is locked, it 159 can still be checked out for reading, compiling, etc. All 160 that locking prevents is a CHECK-IN by anybody but the 161 locker. 162 163 If your RCS file is private, i.e., if you are the only 164 person who is going to deposit revisions into it, strict 165 locking is not needed and you can turn it off. If strict 166 locking is turned off, the owner of the RCS file need not 167 have a lock for check-in; all others still do. Turning 168 strict locking off and on is done with the commands 169 170 rrccss --UU ff..cc and rrccss --LL ff..cc 171 172 If you don't want to clutter your working directory with 173 RCS files, create a subdirectory called RCS in your 174 working directory, and move all your RCS files there. RCS 175 commands will look first into that directory to find 176 needed files. All the commands discussed above will still 177 work, without any modification. (Actually, pairs of RCS 178 and working files can be specified in 3 ways: (a) both are 179 given, (b) only the working file is given, (c) only the 180 RCS file is given. Both RCS and working files may have 181 arbitrary path prefixes; RCS commands pair them up 182 intelligently). 183 184 To avoid the deletion of the working file during check-in 185 (in case you want to continue editing), invoke 186 187 ccii --ll ff..cc or ccii --uu ff..cc 188 189 These commands check in f.c as usual, but perform an 190 implicit check-out. The first form also locks the checked 191 in revision, the second one doesn't. Thus, these options 192 save you one check-out operation. The first form is 193 194 195 19611, May 3 197 198 199 200 201 202RCSINTRO(1L) 1983 RCSINTRO(1L) 203 204 205 useful if locking is strict, the second one if not strict. 206 Both update the identification markers in your working 207 file (see below). 208 209 You can give _c_i the number you want assigned to a checked 210 in revision. Assume all your revisions were numbered 1.1, 211 1.2, 1.3, etc., and you would like to start release 2. 212 The command 213 214 ccii --rr22 ff..cc or ccii --rr22..11 ff..cc 215 216 assigns the number 2.1 to the new revision. From then on, 217 _c_i will number the subsequent revisions with 2.2, 2.3, 218 etc. The corresponding _c_o commands 219 220 ccoo --rr22 ff..cc and ccoo --rr22..11 ff..cc 221 222 retrieve the latest revision numbered 2.x and the revision 223 2.1, respectively. _C_o without a revision number selects 224 the latest revision on the "trunk", i.e., the highest 225 revision with a number consisting of 2 fields. Numbers 226 with more than 2 fields are needed for branches. For 227 example, to start a branch at revision 1.3, invoke 228 229 ccii --rr11..33..11 ff..cc 230 231 This command starts a branch numbered 1 at revision 1.3, 232 and assigns the number 1.3.1.1 to the new revision. For 233 more information about branches, see _r_c_s_f_i_l_e(5L). 234 235 236 AAuuttoommaattiicc IIddeennttiiffiiccaattiioonn 237 238 RCS can put special strings for identification into your 239 source and object code. To obtain such identification, 240 place the marker 241 242 $Header$ 243 244 into your text, for instance inside a comment. RCS will 245 replace this marker with a string of the form 246 247 $Header: filename revision_number date time 248 author state $ 249 250 With such a marker on the first page of each module, you 251 can always see with which revision you are working. RCS 252 keeps the markers up to date automatically. To propagate 253 the markers into your object code, simply put them into 254 literal character strings. In C, this is done as follows: 255 256 static char rcsid[] = "$Header$"; 257 258 The command _i_d_e_n_t extracts such markers from any file, 259 260 261 26211, May 4 263 264 265 266 267 268RCSINTRO(1L) 1983 RCSINTRO(1L) 269 270 271 even object code and dumps. Thus, _i_d_e_n_t lets you find out 272 which revisions of which modules were used in a given 273 program. 274 275 You may also find it useful to put the marker $Log$ into 276 your text, inside a comment. This marker accumulates the 277 log messages that are requested during check-in. Thus, 278 you can maintain the complete history of your file 279 directly inside it. There are several additional 280 identification markers; see _c_o(1L) for details. 281 282IIDDEENNTTIIFFIICCAATTIIOONN 283 Author: Walter F. Tichy, Purdue University, West 284 Lafayette, IN, 47907. 285 Revision Number: 1.2 ; Release Date: 89/05/02 . 286 Copyright (C) 1982, 1988, 1989 by Walter F. Tichy. 287 288SSEEEE AALLSSOO 289 ci(1L), co(1L), ident(1L), merge(1L), rcs(1L), 290 rcsdiff(1L), rcsmerge(1L), rlog(1L), rcsfile(5L), 291 Walter F. Tichy, "Design, Implementation, and Evaluation 292 of a Revision Control System," in _P_r_o_c_e_e_d_i_n_g_s _o_f _t_h_e _6_t_h 293 _I_n_t_e_r_n_a_t_i_o_n_a_l _C_o_n_f_e_r_e_n_c_e _o_n _S_o_f_t_w_a_r_e _E_n_g_i_n_e_e_r_i_n_g, IEEE, 294 Tokyo, Sept. 1982. 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 32811, May 5 329 330 331