31.RP
32.TL
33RCS\*-A System for Version Control
34.sp
35.AU
36Walter F. Tichy
37.AI
38Department of Computer Sciences
39Purdue University
40West Lafayette, Indiana 47907
41.sp
42.AB
43An important problem in program development and maintenance is version control,
44i.e., the task of keeping a software system consisting of many versions and
45configurations well organized.
46The Revision Control System (RCS)
47is a software tool that assists with that task.
48RCS manages revisions of text documents, in particular source programs,
49documentation, and test data.
50It automates the storing, retrieval, logging and identification of revisions,
51and it provides selection mechanisms for composing configurations.
52This paper introduces basic version control concepts and
53discusses the practice of version control
54using RCS.
55For conserving space, RCS stores deltas, i.e., differences between
56successive revisions. Several delta storage methods are discussed.
57Usage statistics show that RCS's delta storage method is
58space and time efficient.
59The paper concludes with a detailed survey of version control tools.
60.sp
61\fBKeywords\fR: configuration management, history management,
62version control, revisions, deltas.
63.AE
64.FS
65An earlier version of this paper was published in
66.I "Software\*-Practice & Experience"
67.B 15 ,
687 (July 1985), 637-654.
69.FE
70.nr VS 18p
71.LP
72.NH
73Introduction
74.PP
75Version control is the task of keeping software
76systems consisting of many versions and configurations well organized.
77The Revision Control System (RCS) is a set of UNIX
78commands that assist with that task.
79.PP
80RCS' primary function is to manage \fIrevision groups\fR.
81A revision group is a set of text documents, called \fIrevisions\fR,
82that evolved from each other. A new revision is
83created by manually editing an existing one.
84RCS organizes the revisions into an ancestral tree. The initial revision
85is the root of the tree, and the tree edges indicate
86from which revision a given one evolved.
87Besides managing individual revision groups, RCS provides
88flexible selection functions for composing configurations.
89RCS may be combined with MAKE\u1\d,
90resulting in a powerful package for version control.
91.PP
92RCS also offers facilities for
93merging updates with customer modifications,
94for distributed software development, and
95for automatic identification.
96Identification is the `stamping'
97of revisions and configurations with unique markers.
98These markers are akin to serial numbers,
99telling software maintainers unambiguously which configuration
100is before them.
101.PP
102RCS is designed for both production and experimental
103environments.
104In production environments,
105access controls detect update conflicts and prevent overlapping changes.
106In experimental environments, where strong controls are
107counterproductive, it is possible to loosen the controls.
108.PP
109Although RCS was originally intended for programs, it is useful for any
110text that is revised frequently and whose previous revisions must be
111preserved. RCS has been applied successfully to store the source
112text for drawings, VLSI layouts, documentation, specifications,
113test data, form letters and articles.
114.PP
115This paper discusses the practice of
116version control using RCS.
117It also introduces basic version control concepts,
118useful for clarifying current practice and designing similar systems.
119Revision groups of individual components are treated in the next three sections,
120and the extensions to configurations follow.
121Because of its size, a survey of version control tools
122appears at the end of the paper.
123.NH
124Getting started with RCS
125.PP
126Suppose a text file \fIf.c\fR is to be placed under control of RCS.
127Invoking the check-in command
128.D(
129ci f.c
130.D)
131creates a new revision group with the contents of
132\fIf.c\fR as the initial
133revision (numbered 1.1)
134and stores the group into the file \fIf.c,v\fR.
135Unless told otherwise, the command deletes \fIf.c\fR.
136It also asks for a description of the group.
137The description should state the common purpose of all revisions in the group,
138and becomes part of the group's documentation.
139All later check-in commands will ask for a log entry,
140which should summarize the changes made.
141(The first revision is assigned a default log message,
142which just records the fact that it is the initial revision.)
143.PP
144Files ending in \fI,v\fR
145are called \fIRCS files\fR (\fIv\fR stands for \fIv\fRersions);
146the others are called working files.
147To get back the working file \fIf.c\fR in the previous example,
148execute the check-out command:
149.D(
150co f.c
151.D)
152.R
153This command extracts the latest revision from
154the revision group \fIf.c,v\fR and writes
155it into \fIf.c\fR.
156The file \fIf.c\fR can now be edited and, when finished,
157checked back in with \fIci\fR:
158.D(
159ci f.c
160.D)
161\fICi\fR assigns number 1.2 to
162the new revision.
163If \fIci\fR complains with the message
164.D(
165ci error: no lock set by <login>
166.D)
167then the system administrator has decided to configure RCS for a
168production environment by enabling the `strict locking feature'.
169If this feature is enabled, all RCS files are initialized
170such that check-in operations require a lock on the previous revision
171(the one from which the current one evolved).
172Locking prevents overlapping modifications if several people work on the same file.
173If locking is required, the revision should
174have been locked during the check-out by using
175the option \fI\-l\fR:
176.D(
177co \-l f.c
178.D)
179Of course it is too late now for the check-out with locking, because
180\fIf.c\fR has already been changed; checking out the file again
181would overwrite the modifications.
182(To prevent accidental overwrites, \fIco\fR senses the presence
183of a working file and asks whether the user really intended to overwrite it.
184The overwriting check-out is sometimes useful for
185backing up to the previous revision.)
186To be able to proceed with the check-in in the present case, first execute
187.D(
188rcs \-l f.c
189.D)
190This command retroactively locks the latest revision, unless someone
191else locked it in the meantime. In this case, the two programmers
192involved have to negotiate whose
193modifications should take precedence.
194.PP
195If an RCS file is private, i.e., if only the owner of the file is expected
196to deposit revisions into it, the strict locking feature is unnecessary and
197may be disabled.
198If strict locking is disabled,
199the owner of the RCS file need not have a lock for check-in.
200For safety reasons, all others
201still do. Turning strict locking off and on is done with the commands:
202.D(
203rcs \-U f.c \fRand\fP rcs \-L f.c
204.D)
205These commands enable or disable the strict locking feature for each RCS file
206individually.
207The system administrator only decides whether strict locking is
208enabled initially.
209.PP
210To reduce the clutter in a working directory, all RCS files can be moved
211to a subdirectory with the name \fIRCS\fR.
212RCS commands look first into that directory for RCS files.
213All the commands presented above work
214with the \fIRCS\fR subdirectory without change.\(dg
215.FS \(dg
216Pairs of RCS and working files can actually be specified in 3 ways:
217a) both are given, b) only the working file is given, c) only the
218RCS file is given.
219If a pair is given, both files may have arbitrary path prefixes;
220RCS commands pair them up intelligently.
221.FE
222.PP
223It may be undesirable that \fIci\fR deletes the working file.
224For instance, sometimes one would like to save the current revision,
225but continue editing.
226Invoking
227.D(
228ci \-l f.c
229.D)
230checks in \fIf.c\fR as usual, but performs an additional
231check-out with locking afterwards. Thus, the working file does
232not disappear after the check-in.
233Similarly, the option
234\fI\-u\fR does a check-in followed by a check-out without
235locking. This option is useful if the file is needed for compilation after the check-in.
236Both options update the identification markers in the working file
237(see below).
238.PP
239Besides the operations \fIci\fR and \fIco\fR, RCS provides the following
240commands:
241.sp 0
242.nr VS 12p
243.vs 12p
244.TS
245tab(%);
246li l.
247ident%extract identification markers
248rcs%change RCS file attributes
249rcsclean%remove unchanged working files (optional)
250rcsdiff%compare revisions
251rcsfreeze%record a configuration (optional)
252rcsmerge%merge revisions
253rlog%read log messages and other information in RCS files
254.TE
255A synopsis of these commands appears in the Appendix.
256.NH 2
257Automatic Identification
258.PP
259RCS can stamp source and object code with special identification strings,
260similar to product and serial numbers.
261To obtain such identification, place the marker
262.D(
263\*sId\*s
264.D)
265into the text of a revision, for instance inside a comment.
266The check-out operation will replace this marker with a string of the form
267.D(
268\*sId: filename revisionnumber date time author state locker \*s
269.D)
270This string need never be touched, because \fIco\fR keeps it
271up to date automatically.
272To propagate the marker into object code, simply put
273it into a literal character string. In C, this is done as follows:
274.D(
275static char rcsid[] = \&"\*sId\*s\&";
276.D)
277The command \fIident\fR extracts such markers from any file, in particular from
278object code.
279\fIIdent\fR helps to find out
280which revisions of which modules were used in a given program.
281It returns a complete and unambiguous component list,
282from which a copy of the program can be reconstructed.
283This facility is invaluable for program maintenance.
284.PP
285There are several additional identification markers, one for each component
286of \*sId\*s.
287The marker
288.D(
289\*sLog\*s
290.D)
291has a similar function. It accumulates
292the log messages that are requested during check-in.
293Thus, one can maintain the complete history of a revision directly inside it,
294by enclosing it in a comment.
| 22.RP
23.TL
24RCS\*-A System for Version Control
25.sp
26.AU
27Walter F. Tichy
28.AI
29Department of Computer Sciences
30Purdue University
31West Lafayette, Indiana 47907
32.sp
33.AB
34An important problem in program development and maintenance is version control,
35i.e., the task of keeping a software system consisting of many versions and
36configurations well organized.
37The Revision Control System (RCS)
38is a software tool that assists with that task.
39RCS manages revisions of text documents, in particular source programs,
40documentation, and test data.
41It automates the storing, retrieval, logging and identification of revisions,
42and it provides selection mechanisms for composing configurations.
43This paper introduces basic version control concepts and
44discusses the practice of version control
45using RCS.
46For conserving space, RCS stores deltas, i.e., differences between
47successive revisions. Several delta storage methods are discussed.
48Usage statistics show that RCS's delta storage method is
49space and time efficient.
50The paper concludes with a detailed survey of version control tools.
51.sp
52\fBKeywords\fR: configuration management, history management,
53version control, revisions, deltas.
54.AE
55.FS
56An earlier version of this paper was published in
57.I "Software\*-Practice & Experience"
58.B 15 ,
597 (July 1985), 637-654.
60.FE
61.nr VS 18p
62.LP
63.NH
64Introduction
65.PP
66Version control is the task of keeping software
67systems consisting of many versions and configurations well organized.
68The Revision Control System (RCS) is a set of UNIX
69commands that assist with that task.
70.PP
71RCS' primary function is to manage \fIrevision groups\fR.
72A revision group is a set of text documents, called \fIrevisions\fR,
73that evolved from each other. A new revision is
74created by manually editing an existing one.
75RCS organizes the revisions into an ancestral tree. The initial revision
76is the root of the tree, and the tree edges indicate
77from which revision a given one evolved.
78Besides managing individual revision groups, RCS provides
79flexible selection functions for composing configurations.
80RCS may be combined with MAKE\u1\d,
81resulting in a powerful package for version control.
82.PP
83RCS also offers facilities for
84merging updates with customer modifications,
85for distributed software development, and
86for automatic identification.
87Identification is the `stamping'
88of revisions and configurations with unique markers.
89These markers are akin to serial numbers,
90telling software maintainers unambiguously which configuration
91is before them.
92.PP
93RCS is designed for both production and experimental
94environments.
95In production environments,
96access controls detect update conflicts and prevent overlapping changes.
97In experimental environments, where strong controls are
98counterproductive, it is possible to loosen the controls.
99.PP
100Although RCS was originally intended for programs, it is useful for any
101text that is revised frequently and whose previous revisions must be
102preserved. RCS has been applied successfully to store the source
103text for drawings, VLSI layouts, documentation, specifications,
104test data, form letters and articles.
105.PP
106This paper discusses the practice of
107version control using RCS.
108It also introduces basic version control concepts,
109useful for clarifying current practice and designing similar systems.
110Revision groups of individual components are treated in the next three sections,
111and the extensions to configurations follow.
112Because of its size, a survey of version control tools
113appears at the end of the paper.
114.NH
115Getting started with RCS
116.PP
117Suppose a text file \fIf.c\fR is to be placed under control of RCS.
118Invoking the check-in command
119.D(
120ci f.c
121.D)
122creates a new revision group with the contents of
123\fIf.c\fR as the initial
124revision (numbered 1.1)
125and stores the group into the file \fIf.c,v\fR.
126Unless told otherwise, the command deletes \fIf.c\fR.
127It also asks for a description of the group.
128The description should state the common purpose of all revisions in the group,
129and becomes part of the group's documentation.
130All later check-in commands will ask for a log entry,
131which should summarize the changes made.
132(The first revision is assigned a default log message,
133which just records the fact that it is the initial revision.)
134.PP
135Files ending in \fI,v\fR
136are called \fIRCS files\fR (\fIv\fR stands for \fIv\fRersions);
137the others are called working files.
138To get back the working file \fIf.c\fR in the previous example,
139execute the check-out command:
140.D(
141co f.c
142.D)
143.R
144This command extracts the latest revision from
145the revision group \fIf.c,v\fR and writes
146it into \fIf.c\fR.
147The file \fIf.c\fR can now be edited and, when finished,
148checked back in with \fIci\fR:
149.D(
150ci f.c
151.D)
152\fICi\fR assigns number 1.2 to
153the new revision.
154If \fIci\fR complains with the message
155.D(
156ci error: no lock set by <login>
157.D)
158then the system administrator has decided to configure RCS for a
159production environment by enabling the `strict locking feature'.
160If this feature is enabled, all RCS files are initialized
161such that check-in operations require a lock on the previous revision
162(the one from which the current one evolved).
163Locking prevents overlapping modifications if several people work on the same file.
164If locking is required, the revision should
165have been locked during the check-out by using
166the option \fI\-l\fR:
167.D(
168co \-l f.c
169.D)
170Of course it is too late now for the check-out with locking, because
171\fIf.c\fR has already been changed; checking out the file again
172would overwrite the modifications.
173(To prevent accidental overwrites, \fIco\fR senses the presence
174of a working file and asks whether the user really intended to overwrite it.
175The overwriting check-out is sometimes useful for
176backing up to the previous revision.)
177To be able to proceed with the check-in in the present case, first execute
178.D(
179rcs \-l f.c
180.D)
181This command retroactively locks the latest revision, unless someone
182else locked it in the meantime. In this case, the two programmers
183involved have to negotiate whose
184modifications should take precedence.
185.PP
186If an RCS file is private, i.e., if only the owner of the file is expected
187to deposit revisions into it, the strict locking feature is unnecessary and
188may be disabled.
189If strict locking is disabled,
190the owner of the RCS file need not have a lock for check-in.
191For safety reasons, all others
192still do. Turning strict locking off and on is done with the commands:
193.D(
194rcs \-U f.c \fRand\fP rcs \-L f.c
195.D)
196These commands enable or disable the strict locking feature for each RCS file
197individually.
198The system administrator only decides whether strict locking is
199enabled initially.
200.PP
201To reduce the clutter in a working directory, all RCS files can be moved
202to a subdirectory with the name \fIRCS\fR.
203RCS commands look first into that directory for RCS files.
204All the commands presented above work
205with the \fIRCS\fR subdirectory without change.\(dg
206.FS \(dg
207Pairs of RCS and working files can actually be specified in 3 ways:
208a) both are given, b) only the working file is given, c) only the
209RCS file is given.
210If a pair is given, both files may have arbitrary path prefixes;
211RCS commands pair them up intelligently.
212.FE
213.PP
214It may be undesirable that \fIci\fR deletes the working file.
215For instance, sometimes one would like to save the current revision,
216but continue editing.
217Invoking
218.D(
219ci \-l f.c
220.D)
221checks in \fIf.c\fR as usual, but performs an additional
222check-out with locking afterwards. Thus, the working file does
223not disappear after the check-in.
224Similarly, the option
225\fI\-u\fR does a check-in followed by a check-out without
226locking. This option is useful if the file is needed for compilation after the check-in.
227Both options update the identification markers in the working file
228(see below).
229.PP
230Besides the operations \fIci\fR and \fIco\fR, RCS provides the following
231commands:
232.sp 0
233.nr VS 12p
234.vs 12p
235.TS
236tab(%);
237li l.
238ident%extract identification markers
239rcs%change RCS file attributes
240rcsclean%remove unchanged working files (optional)
241rcsdiff%compare revisions
242rcsfreeze%record a configuration (optional)
243rcsmerge%merge revisions
244rlog%read log messages and other information in RCS files
245.TE
246A synopsis of these commands appears in the Appendix.
247.NH 2
248Automatic Identification
249.PP
250RCS can stamp source and object code with special identification strings,
251similar to product and serial numbers.
252To obtain such identification, place the marker
253.D(
254\*sId\*s
255.D)
256into the text of a revision, for instance inside a comment.
257The check-out operation will replace this marker with a string of the form
258.D(
259\*sId: filename revisionnumber date time author state locker \*s
260.D)
261This string need never be touched, because \fIco\fR keeps it
262up to date automatically.
263To propagate the marker into object code, simply put
264it into a literal character string. In C, this is done as follows:
265.D(
266static char rcsid[] = \&"\*sId\*s\&";
267.D)
268The command \fIident\fR extracts such markers from any file, in particular from
269object code.
270\fIIdent\fR helps to find out
271which revisions of which modules were used in a given program.
272It returns a complete and unambiguous component list,
273from which a copy of the program can be reconstructed.
274This facility is invaluable for program maintenance.
275.PP
276There are several additional identification markers, one for each component
277of \*sId\*s.
278The marker
279.D(
280\*sLog\*s
281.D)
282has a similar function. It accumulates
283the log messages that are requested during check-in.
284Thus, one can maintain the complete history of a revision directly inside it,
285by enclosing it in a comment.
|
588.ps +2
589.PE
590.ce 1
591Figure 5. A revision tree with reverse and forward deltas.
592.sp 0
593.PP
594Although implementing fast check-out for the latest trunk revision,
595this arrangement has the disadvantage that generation of other revisions
596takes time proportional to the number of deltas applied. For example,
597regenerating the branch tip in Figure 5 requires application of five
598deltas (including the initial one). Since usage statistics show that
599the latest trunk revision is the one that is retrieved in 95 per cent
600of all cases (see the section on usage statistics), biasing check-out time
601in favor of that revision results in significant savings.
602However, careful implementation of the delta application process is
603necessary to provide low retrieval overhead for other revisions, in
604particular for branch tips.
605.PP
606There are several techniques for delta application.
607The naive one is to pass each delta to a general-purpose text editor.
608A prototype of RCS invoked the UNIX editor \fIed\fR both
609for applying deltas and for expanding the identification markers.
610Although easy to implement, performance was poor, owing to the
611high start-up costs and excess generality of \fIed\fR. An intermediate
612version of RCS used a special-purpose, stream-oriented editor.
613This technique reduced the cost of applying a delta to the cost of
614checking out the latest trunk revision. The reason for this behavior
615is that each delta application involves a complete pass over
616the preceding revision.
617.PP
618However, there is a much better algorithm. Note that the deltas are
619line oriented and that most of the work of a stream editor involves
620copying unchanged lines from one revision to the next. A faster
621algorithm avoids unnecessary copying of character strings by using
622a \fIpiece table\fR.
623A piece table is a one-dimensional array, specifying how a given
624revision is `pieced together' from lines in the RCS file.
625Suppose piece table \fIPT\dr\u\fR represents revision \fIr\fR.
626Then \fIPT\dr\u[i]\fR contains the starting position of line \fIi\fR
627of revision \fIr\fR.
628Application of the next delta transforms piece table \fIPT\dr\u\fR
629into \fIPT\dr+1\u\fR. For instance, a delete command removes a
630series of entries from the piece table. An insertion command inserts
631new entries, moving the entries following the insertion point further down the
632array. The inserted entries point to the text lines in the delta.
633Thus, no I/O is involved except for reading the delta itself. When all
634deltas have been applied to the piece table, a sequential pass
635through the table looks up each line in the RCS file and copies it to
636the output file, updating identification markers at the same time.
637Of course, the RCS file must permit random access, since the copied
638lines are scattered throughout that file. Figure 6 illustrates an
639RCS file with two revisions and the corresponding piece tables.
640.ne 13
641.sp 6
642.ce 1
643\fIFigure 6 is not available.\fP
644.sp 5
645.ce 1
646Figure 6. An RCS file and its piece tables
647.sp 0
648.PP
649The piece table approach has the property that the time for applying a single
650delta is roughly determined by the size of the delta, and not by the
651size of the revision. For example, if a delta is
65210 per cent of the size of a revision, then applying it takes only
65310 per cent of the time to generate the latest trunk revision. (The stream
654editor would take 100 per cent.)
655.PP
656There is an important alternative for representing deltas that affects
657performance. SCCS\u3\d,
658a precursor of RCS, uses \fIinterleaved\fR deltas.
659A file containing interleaved deltas is partitioned into blocks of lines.
660Each block has a header that specifies to which revision(s) the block
661belongs. The blocks are sorted out in such a way that a single
662pass over the file can pick up all the lines belonging to a given
663revision. Thus, the regeneration time for all revisions is the same:
664all headers must be inspected, and the associated blocks either copied
665or skipped. As the number of revisions increases, the cost of retrieving
666any revision is much higher than the cost of checking out the
667latest trunk revision with reverse deltas. A detailed comparison
668of SCCS's interleaved deltas and RCS's reverse deltas can be found
669in Reference 4.
670This reference considers the version of RCS with the
671stream editor only. The piece table method improves performance
672further, so that RCS is always faster than SCCS, except if 10
673or more deltas are applied.
674.PP
675Additional speed-up for both delta methods can be obtained by caching
676the most recently generated revision, as has been implemented in DSEE.\u5\d
677With caching, access time to frequently used revisions can approach normal file
678access time, at the cost of some additional space.
679.NH
680Locking: A Controversial Issue
681.PP
682The locking mechanism for RCS was difficult to design.
683The problem and its solution are first presented in their `pure' form,
684followed by a discussion of the complications
685caused by `real-world' considerations.
686.PP
687RCS must prevent two or more persons from depositing competing changes of the
688same revision.
689Suppose two programmers check out revision 2.4 and
690modify it. Programmer A checks in a revision before programmer B\&.
691Unfortunately, programmer B has not seen A's
692changes, so the effect is that A's changes are covered up by B's deposit.
693A's changes are not lost since all revisions
694are saved, but they are confined to a single revision.\(dd
695.FS \(dd
696Note that this problem is entirely different from the atomicity problem.
697Atomicity means that
698concurrent update operations on the same RCS file cannot be permitted,
699because that may result in inconsistent data.
700Atomic updates are essential (and implemented in RCS),
701but do not solve the conflict discussed here.
702.FE
703.PP
704This conflict is prevented in RCS by locking.
705Whenever someone intends to edit a revision (as opposed
706to reading or compiling it), the revision should be checked out
707and locked,
708using the \fI\-l\fR option on \fIco\fR. On subsequent check-in,
709\fIci\fR tests the lock and then removes it.
710At most one programmer at a time may
711lock a particular revision, and only this programmer may check in
712the succeeding revision.
713Thus, while a revision is locked, it is the exclusive responsibility
714of the locker.
715.PP
716An important maxim for software tools like RCS is that they must
717not stand in the way of making progress with a project.
718This consideration leads to several weakenings of the locking mechanism.
719First of all, even if a revision is locked, it can
720still be checked out. This is necessary if other people
721wish to compile or inspect the locked revision
722while the next one is in preparation. The only operations they
723cannot do are to lock the revision or to check in the succeeding one. Secondly,
724check-in operations on other branches in the RCS file are still possible; the
725locking of one revision does not affect any other revision.
726Thirdly, revisions are occasionally locked for a long period of time
727because a programmer is absent or otherwise unable to complete
728the assignment. If another programmer has to make a pressing change,
729there are the following three alternatives for making progress:
730a) find out who is holding the lock and ask that person to release it;
731b) check out the locked revision, modify it, check it
732in on a branch, and merge the changes later;
733c) break the lock. Breaking a lock leaves a highly visible
734trace, namely an electronic mail message that is sent automatically to the
735holder of the lock, recording the breaker and a commentary requested from him.
736Thus, breaking locks is tolerated under certain circumstances,
737but will not go unnoticed.
738Experience has shown that the automatic mail message attaches a high enough
739stigma to lock breaking,
740such that programmers break locks only in real emergencies,
741or when a co-worker resigns and leaves locked revisions behind.
742.PP
743If an RCS file is private, i.e., when a programmer owns an RCS file
744and does not expect anyone else to perform check-in operations,
745locking is an unnecessary nuisance.
746In this case,
747the `strict locking feature' discussed earlier may be disabled,
748provided that file protection
749is set such that only the owner may write the RCS file.
750This has the effect that only the owner can check-in revisions,
751and that no lock is needed for doing so.
752.PP
753As added protection,
754each RCS file contains an access list that specifies the users
755who may execute update operations. If an access list is empty,
756only normal UNIX file protection applies. Thus, the access list is
757useful for restricting the set of people who would otherwise have update
758permission. Just as with locking, the access list
759has no effect on read-only operations such as \fIco\fR. This approach
760is consistent with the UNIX philosophy of openness, which contributes
761to a productive software development environment.
762.NH
763Configuration Management
764.PP
765The preceding sections described how RCS deals with revisions of individual
766components; this section discusses how to handle configurations.
767A configuration is a set of revisions, where each revision comes
768from a different revision group, and the revisions are selected
769according to a certain criterion.
770For example,
771in order to build a functioning compiler, the `right'
772revisions from the scanner, the parser, the optimizer
773and the code generator must be combined.
774RCS, in conjunction with MAKE,
775provides a number of facilities to effect a smooth selection.
776.NH 2
777RCS Selection Functions
778.PP
779.IP "\fIDefault selection\fR"
780.sp 0
781During development, the usual selection criterion is to choose
782the latest revision of all components. The \fIco\fR command
783makes this selection by default. For example, the command
784.D(
785co *,v
786.D)
787retrieves the latest revision on the default branch of each RCS file
788in the current directory.
789The default branch is usually the trunk, but may be
790set to be a side branch.
791Side branches as defaults are needed in distributed software development,
792as discussed in the section on the RCS revision tree.
793.sp
794.IP "\fIRelease based selection\fR"
795.sp 0
796Specifying a release or branch number selects the latest revision in
797that release or branch.
798For instance,
799.D(
800co \-r2 *,v
801.D)
802retrieves the latest revision with release number 2 from each RCS file.
803This selection is convenient if a release has been completed and
804development has moved on to the next release.
805.sp
806.IP "\fIState and author based selection\fR"
807.sp 0
808If the highest level number within a given release number
809is not the desired one,
810the state attribute can help. For example,
811.D(
812co \-r2 \-sReleased *,v
813.D)
814retrieves the latest revision with release number 2 whose state attribute
815is `Released'.
816Of course, the state attribute has to be set appropriately, using the
817\fIci\fR or \fIrcs\fR commands.
818Another alternative is to select a revision by its author,
819using the \fI\-w\fR option.
820.sp
821.IP "\fIDate based selection\fR"
822.sp 0
823Revisions may also be selected by date.
824Suppose a release of an entire system was
825completed and current on March 4, at 1:00 p.m. local time. Then the command
826.D(
827co \-d'March 4, 1:00 pm LT' *,v
828.D)
829checks out all the components of that release, independent of the numbering.
830The \fI\-d\fR option specifies a `cutoff date', i.e.,
831the revision selected has a check-in date that
832is closest to, but not after the date given.
833.IP "\fIName based selection\fR"
834.sp 0
835The most powerful selection function is based on assigning symbolic
836names to revisions and branches.
837In large systems, a single release number or date is not sufficient
838to collect the appropriate revisions from all groups.
839For example, suppose one wishes to combine release 2
840of one subsystem and release 15 of another.
841Most likely, the creation dates of those releases differ also.
842Thus, a single revision number or date passed to the \fIco\fR command
843will not suffice to select the right revisions.
844Symbolic revision numbers solve this problem.
845Each RCS file may contain a set of symbolic names that are mapped
846to numeric revision numbers. For example, assume
847the symbol \fIV3\fR is bound to release number 2 in file \fIs,v\fR, and to
848revision number 15.9 in \fIt,v\fR.
849Then the single command
850.D(
851co \-rV3 s,v t,v
852.D)
853retrieves the latest revision of release 2 from \fIs,v\fR,
854and revision 15.9 from \fIt,v\fR.
855In a large system with many modules, checking out all
856revisions with one command greatly simplifies configuration management.
857.PP
858Judicious use of symbolic revision numbers helps with organizing
859large configurations.
860A special command, \fIrcsfreeze\fR,
861assigns a symbolic revision number to a selected revision
862in every RCS file.
863\fIRcsfreeze\fR effectively freezes a configuration.
864The assigned symbolic revision number selects all components
865of the configuration.
866If necessary, symbolic numbers
867may even be intermixed with numeric ones. Thus, \fIV3.5\fR in the
868above example
869would select revision 2.5 in \fIs,v\fR and branch 15.9.5 in \fIt,v\fR.
870.PP
871The options \fI\-r\fR, \fI\-s\fR, \fI\-w\fR and \fI\-d\fR
872may be combined. If a branch is given, the latest revision
873on that branch satisfying all conditions is retrieved;
874otherwise, the default branch is used.
875.NH 2
876Combining MAKE and RCS
877.PP
878MAKE\u1\d
879is a program that processes configurations.
880It is driven by configuration specifications
881recorded in a special file, called a `Makefile'.
882MAKE avoids redundant processing steps
883by comparing creation dates of source and processed objects.
884For example, when instructed to compile all
885modules of a given system, it only recompiles
886those source modules that were changed
887since they were processed last.
888.PP
889MAKE has been extended with an auto-checkout feature for RCS.*
890.FS *
891This auto-checkout extension is available only in some versions of MAKE,
892e.g. GNU MAKE.
893.FE
894When a certain file to be processed is not present,
895MAKE attempts a check-out operation.
896If successful, MAKE performs the required processing, and then deletes
897the checked out file to conserve space.
898The selection parameters discussed above can be passed to MAKE
899either as parameters, or directly embedded in the Makefile.
900MAKE has also been extended to search the subdirectory named \fIRCS\fR
901for needed files, rather than just the current working directory.
902However, if a working file is present, MAKE totally ignores the corresponding
903RCS file and uses the working file.
904(In newer versions of MAKE distributed by AT&T and others,
905auto-checkout can be
906achieved with the rule DEFAULT, instead of a special extension of MAKE.
907However, a file checked out by the rule DEFAULT
908will not be deleted after processing. \fIRcsclean\fR can be
909used for that purpose.)
910.PP
911With auto-checkout, RCS/MAKE can effect a selection rule
912especially tuned for multi-person software development and maintenance.
913In these situations,
914programmers should obtain configurations that consist of
915the revisions they have personally checked out plus the latest
916checked in revision of all other revision groups.
917This schema can be set up as follows.
918.PP
919Each programmer chooses a working directory
920and places into it a symbolic link, named \fIRCS\fR,
921to the directory containing the relevant RCS files.
922The symbolic link makes sure that \fIco\fR and \fIci\fR
923operations need only specify the working files, and that
924the Makefile need not be changed.
925The programmer then checks out the needed files and modifies them.
926If MAKE is invoked,
927it composes configurations by selecting those
928revisions that are checked out, and the rest from the
929subdirectory \fIRCS\fR.
930The latter selection may be controlled by a symbolic
931revision number or any of the other selection criteria.
932If there are several programmers editing in separate working directories,
933they are insulated from each other's changes until checking in their
934modifications.
935.PP
936Similarly, a maintainer can recreate an older configuration
937by starting to work in an empty working directory.
938During the initial MAKE invocation, all revisions are selected from RCS files.
939As the maintainer checks out files and modifies them,
940a new configuration is gradually built up.
941Every time MAKE is invoked, it substitutes the modified revisions
942into the configuration being manipulated.
943.PP
944A final application of RCS is to use it for storing Makefiles.
945Revision groups of Makefiles represent
946multiple versions of configurations.
947Whenever a configuration is baselined or distributed,
948the best approach is to unambiguously fix
949the configuration with a symbolic revision number by calling
950\fIrcsfreeze\fR,
951to embed that symbol into the Makefile, and to
952check in the Makefile (using the same symbolic revision number).
953With this approach, old configurations
954can be regenerated easily and reliably.
955.NH
956Usage Statistics
957.PP
958The following usage statistics were collected on two DEC VAX-11/780
959computers of the Purdue Computer Science Department. Both machines
960are mainly used for research purposes. Thus, the data
961reflect an environment in which the majority of projects
962involve prototyping and advanced software development,
963but relatively little long-term maintenance.
964.PP
965For the first experiment,
966the \fIci\fR and \fIco\fR operations were instrumented
967to log the number of backward and forward deltas applied.
968The data were collected during a 13 month period
969from Dec. 1982 to Dec. 1983.
970Table I summarizes the results.
971.sp 0
972.nr VS 12p
973.vs 12p
974.TS
975center,box,tab(#);
976c|c|c|c|c s|c s
977c|c|c|c|c s|c s
978l|n|n|n|n n|n n.
979Operation#Total#Total deltas#Mean deltas#Operations#Branch
980 #operations #applied#applied#with >1 delta#operations
981_
982co # 7867# 9320#1.18#509#(6%)#203#(3%)
983ci # 3468# 2207#0.64# 85#(2%)# 75#(2%)
984ci & co#11335#11527#1.02#594#(5%)#278#(2%)
985.TE
986.ce 1
987Table I. Statistics for \fIco\fR and \fIci\fR operations.
988.nr VS 18p
989.vs 18p
990.PP
991The first two lines show statistics for check-out and check-in;
992the third line shows the combination.
993Recall that \fIci\fR performs an implicit check-out to obtain
994a revision for computing the delta.
995In all measures presented, the most recent revision (stored intact)
996counts as one delta. The number of deltas applied represents
997the number of passes necessary, where the first `pass' is a copying step.
998.PP
999Note that the check-out operation is executed more than
1000twice as frequently as the check-in operation.
1001The fourth column gives the mean number of deltas
1002applied in all three cases.
1003For \fIci\fR, the mean number of deltas applied is less
1004than one.
1005The reasons are that the initial check-in requires no delta at all, and that
1006the only time \fIci\fR requires more than one delta is for branches.
1007Column 5 shows the actual number of operations that applied more than one
1008delta.
1009The last column indicates that branches were not used often.
1010.PP
1011The last three columns demonstrate that the most recent trunk revision
1012is by far the most frequently accessed.
1013For RCS, check-out of
1014this revision is a simple copy operation, which is the absolute minimum
1015given the copy-semantics of \fIco\fR.
1016Access to older revisions and branches
1017is more common in non-academic environments,
1018yet even if access to older deltas were an order
1019of magnitude more frequent,
1020the combined average number of deltas applied would still be below 1.2.
1021Since RCS is faster than SCCS until up to 10 delta applications,
1022reverse deltas are clearly the method of choice.
1023.PP
1024The second experiment, conducted in March of 1984,
1025involved surveying the existing RCS files
1026on our two machines. The goal was to determine the mean number of
1027revisions per RCS file, as well as the space consumed by them.
1028Table II shows the results. (Tables I and II were produced at different
1029times and are unrelated.)
1030.sp 0
1031.nr VS 12p
1032.vs 12p
1033.TS
1034center,box,tab(#);
1035c | c | c | c | c | c | c
1036c | c | c | c | c | c | c
1037l | n | n | n | n | n | n.
1038 #Total RCS#Total#Mean#Mean size of#Mean size of#Overhead
1039 #files#revisions#revisions#RCS files#revisions
1040_
1041All files #8033#11133#1.39#6156#5585#1.10
1042Files with#1477# 4578#3.10#8074#6041#1.34
1043\(>= 2 deltas
1044.TE
1045.ce 1
1046Table II. Statistics for RCS files.
1047.nr VS 18p
1048.vs 18p
1049.PP
1050The mean number of revisions per RCS file is 1.39.
1051Columns 5 and 6 show the mean sizes (in bytes) of an RCS file
1052and of the latest revision of each RCS file, respectively.
1053The `overhead' column contains the ratio of the mean sizes.
1054Assuming that all revisions in an RCS file are approximately the same size,
1055this ratio gives a measure of the space consumed by the extra revisions.
1056.PP
1057In our sample, over 80 per cent of the RCS files contained only a single revision.
1058The reason is that our
1059systems programmers routinely check in all source files
1060on the distribution tapes, even though they may never touch them again.
1061To get a better indication of how much space savings are possible
1062with deltas, all measures with those files
1063that contained 2 or more revisions were recomputed. Only for those files
1064is RCS necessary.
1065As shown in the second line, the average number of revisions for those files is
10663.10, with an overhead of 1.34. This means that the extra 2.10 deltas
1067require 34 per cent extra space, or
106816 per cent per extra revision.
1069Rochkind\u3\d
1070measured the space consumed by SCCS, and
1071reported an average of 5 revisions per group
1072and an overhead of 1.37 (or about 9 per cent per extra revision).
1073In a later paper, Glasser\u6\d
1074observed an average of 7 revisions per group in a single, large project,
1075but provided no overhead figure.
1076In his paper on DSEE\u5\d,
1077Leblang reported that delta storage combined with blank compression
1078results in an overhead of a mere 1\-2 per cent per revision.
1079Since leading blanks accounted for about 20 per cent of the surveyed Pascal
1080programs, a revision group with 5\-10 members was smaller
1081than a single cleartext copy.
1082.PP
1083The above observations demonstrate clearly that the space needed
1084for extra revisions is small. With delta storage, the luxury of
1085keeping multiple revisions online is certainly affordable.
1086In fact, introducing a system with delta storage may reduce
1087storage requirements, because programmers often save back-up copies
1088anyway. Since back-up copies are stored much more efficiently with deltas,
1089introducing a system such as RCS may
1090actually free a considerable amount of space.
1091.NH
1092Survey of Version Control Tools
1093.PP
1094The need to keep back-up copies of software arose when
1095programs and data were no longer stored on paper media, but were entered
1096from terminals and stored on disk.
1097Back-up copies are desirable for reliability, and many modern editors
1098automatically save a back-up copy for every file touched.
1099This strategy
1100is valuable for short-term back-ups, but not suitable for long-term
1101version control, since an existing back-up copy is overwritten whenever the
1102corresponding file is edited.
1103.PP
1104Tape archives are suitable for long-term, offline storage.
1105If all changed files are dumped on a back-up tape once per day, old revisions
1106remain accessible. However, tape archives are unsatisfactory
1107for version control in several ways. First, backing up the file
1108system every 24 hours does not capture intermediate revisions.
1109Secondly, the old revisions are not online,
1110and accessing them is tedious and time-consuming.
1111In particular, it is impractical to
1112compare several old revisions of a group,
1113because that may require mounting and searching several tapes.
1114Tape archives are important fail-safe tools in the
1115event of catastrophic disk failures or accidental deletions,
1116but they are ill-suited for version control.
1117Conversely, version control tools do not obviate the
1118need for tape archives.
1119.PP
1120A natural technique for keeping several old revisions online is
1121to never delete a file.
1122Editing a file
1123simply creates a new file with the same
1124name, but with a different sequence number.
1125This technique, available as an option in DEC's VMS operating system,
1126turns out to be inadequate for version control.
1127First, it is prohibitively expensive in terms of storage costs,
1128especially since no data compression techniques are employed.
1129Secondly, indiscriminately storing every change produces too many
1130revisions, and programmers have difficulties distinguishing them.
1131The proliferation of revisions forces programmers to spend much time on
1132finding and deleting useless files.
1133Thirdly, most of the support functions like locking, logging,
1134revision selection,
1135and identification described in this paper are not available.
1136.PP
1137An alternative approach is to separate editing from revision control.
1138The user may repeatedly edit a given revision,
1139until freezing it with an explicit command.
1140Once a revision is frozen, it is stored permanently and can no longer be modified.
1141(In RCS, freezing a revisions is done with \fIci\fR.)
1142Editing a frozen revision implicitly creates a new one, which
1143can again be changed repeatedly until it is frozen itself.
1144This approach saves exactly those revisions that the user
1145considers important, and keeps the number of revisions manageable.
1146IBM's CLEAR/CASTER\u7\d,
1147AT&T's SCCS\u3\d,
1148CMU's SDC\u8\d
1149and DEC's CMS\u9\d,
1150are examples of version control systems using this approach.
1151CLEAR/CASTER maintains a data base of programs, specifications,
1152documentation and messages, using deltas.
1153Its goal is to provide control over the development process from a
1154management viewpoint.
1155SCCS stores multiple revisions of source text in an ancestral tree,
1156records a log entry for each revision,
1157provides access control, and has facilities
1158for uniquely identifying each revision.
1159An efficient delta technique
1160reduces the space consumed by each revision group.
1161SDC is much simpler than SCCS because it stores not more than
1162two revisions. However, it maintains a complete log for all old
1163revisions, some of which may be on back-up tape.
1164CMS, like SCCS, manages tree-structured revision groups,
1165but offers no identification mechanism.
1166.PP
1167Tools for dealing with configurations are still in a state of flux.
1168SCCS, SDC and CMS can be combined with MAKE or MAKE-like programs.
1169Since flexible selection rules are missing from all these tools,
1170it is sometimes difficult
1171to specify precisely which revision of each group
1172should be passed to MAKE for building a desired configuration.
1173The Xerox Cedar system\u10\d
1174provides a `System Modeller' that can rebuild
1175a configuration from an arbitrary set of module revisions.
1176The revisions of a module are only distinguished by creation time,
1177and there is no tool for managing groups.
1178Since the selection rules are primitive,
1179the System Modeller appears to be somewhat tedious to use.
1180Apollo's DSEE\u5\d
1181is a sophisticated software engineering environment.
1182It manages revision groups in a way similar to SCCS and CMS. Configurations
1183are built using `configuration threads'.
1184A configuration thread states which revision of each group
1185named in a configuration should be chosen.
1186A configuration thread may contain dynamic specifiers
1187(e.g., `choose the revisions I am currently working on,
1188and the most recent revisions otherwise'), which are bound
1189automatically at build time.
1190It also provides a notification mechanism for alerting
1191maintainers about the need to rebuild a system after a change.
1192.PP
1193RCS is based on a general model for describing
1194multi-version/multi-configuration systems\u11\d.
1195The model describes systems using AND/OR graphs, where AND nodes represent
1196configurations, and OR nodes represent version groups.
1197The model gives rise to a suit of selection rules for
1198composing configurations, almost all of which are implemented in RCS.
1199The revisions selected by RCS are passed to MAKE for configuration building.
1200Revision group management is modelled after SCCS.
1201RCS retains SCCS's best features,
1202but offers a significantly simpler user interface,
1203flexible selection rules, adequate integration with MAKE
1204and improved identification.
1205A detailed comparison of RCS and SCCS appears in Reference 4.
1206.PP
1207An important component of all revision control systems
1208is a program for computing deltas.
1209SCCS and RCS use the program \fIdiff\fR\u2\d,
1210which first computes the longest common substring of two
1211revisions, and then produces the delta from that substring.
1212The delta is simply an edit script consisting of deletion and
1213insertion commands that generate one revision from the other.
1214.PP
1215A delta based on a longest common substring is not necessarily minimal,
1216because it does not take advantage of crossing block moves.
1217Crossing block moves arise if two or more blocks of lines
1218(e.g., procedures)
1219appear in a different order in two revisions.
1220An edit script derived from a longest common substring
1221first deletes the shorter of the two blocks, and then reinserts it.
1222Heckel\u12\d
1223proposed an algorithm for detecting block moves, but
1224since the algorithm is based on heuristics,
1225there are conditions
1226under which the generated delta is far from minimal.
1227DSEE uses this algorithm combined with blank compression,
1228apparently with satisfactory overall results.
1229A new algorithm that is guaranteed to produce a minimal delta based on
1230block moves appears in Reference 13.
1231A future release of RCS will use this algorithm.
1232.PP
1233\fIAcknowledgements\fR:
1234Many people have helped make RCS a success by contributed criticisms, suggestions,
1235corrections, and even whole new commands (including manual pages).
1236The list of people is too long to be
1237reproduced here, but my sincere thanks for their help and
1238goodwill goes to all of them.
1239.sp
1240.nr VS 12p
1241.vs 12p
1242.SH
1243Appendix: Synopsis of RCS Operations
1244.LP
1245.IP "\fIci\fP \fB\- check in revisions\fP"
1246.sp 0
1247\fICi\fR stores the contents of a working file into the
1248corresponding RCS file as a new revision.
1249If the RCS file doesn't exist, \fIci\fR creates it.
1250\fICi\fR removes the working file, unless one of the options
1251\fI\-u\fR or \fI\-l\fR is present.
1252For each check-in, \fIci\fR asks for a commentary
1253describing the changes relative to the previous revision.
1254.sp 1
1255\fICi\fR assigns the revision number given by the \fI\-r\fR option;
1256if that option is missing, it derives the number from the
1257lock held by the user; if there is no lock and locking is not strict,
1258\fIci\fR increments the number of the latest revision on the trunk.
1259A side branch can only be started by explicitly specifying its
1260number with the \fI\-r\fR option during check-in.
1261.sp 1
1262\fICi\fR also determines
1263whether the revision to be checked in is different from the
1264previous one, and asks whether to proceed if not.
1265This facility simplifies check-in operations for large systems,
1266because one need not remember which files were changed.
1267.sp 1
1268The option \fI\-k\fR searches the checked in file for identification
1269markers containing
1270the attributes
1271revision number, check-in date, author and state, and assigns these
1272to the new revision rather than computing them. This option is
1273useful for software distribution: Recipients of distributed software
1274using RCS should check in updates with the \fI\-k\fR option.
1275This convention guarantees that revision numbers, check-in dates,
1276etc., are the same at all sites.
1277.IP "\fIco\fP \fB\- check out revisions\fP"
1278.sp 0
1279\fICo\fR retrieves revisions according to revision number,
1280date, author and state attributes. It either places the revision
1281into the working file, or prints it on the standard output.
1282\fICo\fR always expands the identification markers.
1283.IP "\fIident\fP \fB\- extract identification markers\fP"
1284.sp 0
1285\fIIdent\fR extracts the identification markers expanded by \fIco\fR
1286from any file and prints them.
1287.IP "\fIrcs\fP \fB\- change RCS file attributes\fP"
1288.sp 0
1289\fIRcs\fR is an administrative operation that changes access lists,
1290locks, unlocks, breaks locks, toggles the strict-locking feature,
1291sets state attributes and symbolic revision numbers, changes the
1292description, and deletes revisions. A revision can
1293only be deleted if it is not the fork of a side branch.
| 581.ps +2
582.PE
583.ce 1
584Figure 5. A revision tree with reverse and forward deltas.
585.sp 0
586.PP
587Although implementing fast check-out for the latest trunk revision,
588this arrangement has the disadvantage that generation of other revisions
589takes time proportional to the number of deltas applied. For example,
590regenerating the branch tip in Figure 5 requires application of five
591deltas (including the initial one). Since usage statistics show that
592the latest trunk revision is the one that is retrieved in 95 per cent
593of all cases (see the section on usage statistics), biasing check-out time
594in favor of that revision results in significant savings.
595However, careful implementation of the delta application process is
596necessary to provide low retrieval overhead for other revisions, in
597particular for branch tips.
598.PP
599There are several techniques for delta application.
600The naive one is to pass each delta to a general-purpose text editor.
601A prototype of RCS invoked the UNIX editor \fIed\fR both
602for applying deltas and for expanding the identification markers.
603Although easy to implement, performance was poor, owing to the
604high start-up costs and excess generality of \fIed\fR. An intermediate
605version of RCS used a special-purpose, stream-oriented editor.
606This technique reduced the cost of applying a delta to the cost of
607checking out the latest trunk revision. The reason for this behavior
608is that each delta application involves a complete pass over
609the preceding revision.
610.PP
611However, there is a much better algorithm. Note that the deltas are
612line oriented and that most of the work of a stream editor involves
613copying unchanged lines from one revision to the next. A faster
614algorithm avoids unnecessary copying of character strings by using
615a \fIpiece table\fR.
616A piece table is a one-dimensional array, specifying how a given
617revision is `pieced together' from lines in the RCS file.
618Suppose piece table \fIPT\dr\u\fR represents revision \fIr\fR.
619Then \fIPT\dr\u[i]\fR contains the starting position of line \fIi\fR
620of revision \fIr\fR.
621Application of the next delta transforms piece table \fIPT\dr\u\fR
622into \fIPT\dr+1\u\fR. For instance, a delete command removes a
623series of entries from the piece table. An insertion command inserts
624new entries, moving the entries following the insertion point further down the
625array. The inserted entries point to the text lines in the delta.
626Thus, no I/O is involved except for reading the delta itself. When all
627deltas have been applied to the piece table, a sequential pass
628through the table looks up each line in the RCS file and copies it to
629the output file, updating identification markers at the same time.
630Of course, the RCS file must permit random access, since the copied
631lines are scattered throughout that file. Figure 6 illustrates an
632RCS file with two revisions and the corresponding piece tables.
633.ne 13
634.sp 6
635.ce 1
636\fIFigure 6 is not available.\fP
637.sp 5
638.ce 1
639Figure 6. An RCS file and its piece tables
640.sp 0
641.PP
642The piece table approach has the property that the time for applying a single
643delta is roughly determined by the size of the delta, and not by the
644size of the revision. For example, if a delta is
64510 per cent of the size of a revision, then applying it takes only
64610 per cent of the time to generate the latest trunk revision. (The stream
647editor would take 100 per cent.)
648.PP
649There is an important alternative for representing deltas that affects
650performance. SCCS\u3\d,
651a precursor of RCS, uses \fIinterleaved\fR deltas.
652A file containing interleaved deltas is partitioned into blocks of lines.
653Each block has a header that specifies to which revision(s) the block
654belongs. The blocks are sorted out in such a way that a single
655pass over the file can pick up all the lines belonging to a given
656revision. Thus, the regeneration time for all revisions is the same:
657all headers must be inspected, and the associated blocks either copied
658or skipped. As the number of revisions increases, the cost of retrieving
659any revision is much higher than the cost of checking out the
660latest trunk revision with reverse deltas. A detailed comparison
661of SCCS's interleaved deltas and RCS's reverse deltas can be found
662in Reference 4.
663This reference considers the version of RCS with the
664stream editor only. The piece table method improves performance
665further, so that RCS is always faster than SCCS, except if 10
666or more deltas are applied.
667.PP
668Additional speed-up for both delta methods can be obtained by caching
669the most recently generated revision, as has been implemented in DSEE.\u5\d
670With caching, access time to frequently used revisions can approach normal file
671access time, at the cost of some additional space.
672.NH
673Locking: A Controversial Issue
674.PP
675The locking mechanism for RCS was difficult to design.
676The problem and its solution are first presented in their `pure' form,
677followed by a discussion of the complications
678caused by `real-world' considerations.
679.PP
680RCS must prevent two or more persons from depositing competing changes of the
681same revision.
682Suppose two programmers check out revision 2.4 and
683modify it. Programmer A checks in a revision before programmer B\&.
684Unfortunately, programmer B has not seen A's
685changes, so the effect is that A's changes are covered up by B's deposit.
686A's changes are not lost since all revisions
687are saved, but they are confined to a single revision.\(dd
688.FS \(dd
689Note that this problem is entirely different from the atomicity problem.
690Atomicity means that
691concurrent update operations on the same RCS file cannot be permitted,
692because that may result in inconsistent data.
693Atomic updates are essential (and implemented in RCS),
694but do not solve the conflict discussed here.
695.FE
696.PP
697This conflict is prevented in RCS by locking.
698Whenever someone intends to edit a revision (as opposed
699to reading or compiling it), the revision should be checked out
700and locked,
701using the \fI\-l\fR option on \fIco\fR. On subsequent check-in,
702\fIci\fR tests the lock and then removes it.
703At most one programmer at a time may
704lock a particular revision, and only this programmer may check in
705the succeeding revision.
706Thus, while a revision is locked, it is the exclusive responsibility
707of the locker.
708.PP
709An important maxim for software tools like RCS is that they must
710not stand in the way of making progress with a project.
711This consideration leads to several weakenings of the locking mechanism.
712First of all, even if a revision is locked, it can
713still be checked out. This is necessary if other people
714wish to compile or inspect the locked revision
715while the next one is in preparation. The only operations they
716cannot do are to lock the revision or to check in the succeeding one. Secondly,
717check-in operations on other branches in the RCS file are still possible; the
718locking of one revision does not affect any other revision.
719Thirdly, revisions are occasionally locked for a long period of time
720because a programmer is absent or otherwise unable to complete
721the assignment. If another programmer has to make a pressing change,
722there are the following three alternatives for making progress:
723a) find out who is holding the lock and ask that person to release it;
724b) check out the locked revision, modify it, check it
725in on a branch, and merge the changes later;
726c) break the lock. Breaking a lock leaves a highly visible
727trace, namely an electronic mail message that is sent automatically to the
728holder of the lock, recording the breaker and a commentary requested from him.
729Thus, breaking locks is tolerated under certain circumstances,
730but will not go unnoticed.
731Experience has shown that the automatic mail message attaches a high enough
732stigma to lock breaking,
733such that programmers break locks only in real emergencies,
734or when a co-worker resigns and leaves locked revisions behind.
735.PP
736If an RCS file is private, i.e., when a programmer owns an RCS file
737and does not expect anyone else to perform check-in operations,
738locking is an unnecessary nuisance.
739In this case,
740the `strict locking feature' discussed earlier may be disabled,
741provided that file protection
742is set such that only the owner may write the RCS file.
743This has the effect that only the owner can check-in revisions,
744and that no lock is needed for doing so.
745.PP
746As added protection,
747each RCS file contains an access list that specifies the users
748who may execute update operations. If an access list is empty,
749only normal UNIX file protection applies. Thus, the access list is
750useful for restricting the set of people who would otherwise have update
751permission. Just as with locking, the access list
752has no effect on read-only operations such as \fIco\fR. This approach
753is consistent with the UNIX philosophy of openness, which contributes
754to a productive software development environment.
755.NH
756Configuration Management
757.PP
758The preceding sections described how RCS deals with revisions of individual
759components; this section discusses how to handle configurations.
760A configuration is a set of revisions, where each revision comes
761from a different revision group, and the revisions are selected
762according to a certain criterion.
763For example,
764in order to build a functioning compiler, the `right'
765revisions from the scanner, the parser, the optimizer
766and the code generator must be combined.
767RCS, in conjunction with MAKE,
768provides a number of facilities to effect a smooth selection.
769.NH 2
770RCS Selection Functions
771.PP
772.IP "\fIDefault selection\fR"
773.sp 0
774During development, the usual selection criterion is to choose
775the latest revision of all components. The \fIco\fR command
776makes this selection by default. For example, the command
777.D(
778co *,v
779.D)
780retrieves the latest revision on the default branch of each RCS file
781in the current directory.
782The default branch is usually the trunk, but may be
783set to be a side branch.
784Side branches as defaults are needed in distributed software development,
785as discussed in the section on the RCS revision tree.
786.sp
787.IP "\fIRelease based selection\fR"
788.sp 0
789Specifying a release or branch number selects the latest revision in
790that release or branch.
791For instance,
792.D(
793co \-r2 *,v
794.D)
795retrieves the latest revision with release number 2 from each RCS file.
796This selection is convenient if a release has been completed and
797development has moved on to the next release.
798.sp
799.IP "\fIState and author based selection\fR"
800.sp 0
801If the highest level number within a given release number
802is not the desired one,
803the state attribute can help. For example,
804.D(
805co \-r2 \-sReleased *,v
806.D)
807retrieves the latest revision with release number 2 whose state attribute
808is `Released'.
809Of course, the state attribute has to be set appropriately, using the
810\fIci\fR or \fIrcs\fR commands.
811Another alternative is to select a revision by its author,
812using the \fI\-w\fR option.
813.sp
814.IP "\fIDate based selection\fR"
815.sp 0
816Revisions may also be selected by date.
817Suppose a release of an entire system was
818completed and current on March 4, at 1:00 p.m. local time. Then the command
819.D(
820co \-d'March 4, 1:00 pm LT' *,v
821.D)
822checks out all the components of that release, independent of the numbering.
823The \fI\-d\fR option specifies a `cutoff date', i.e.,
824the revision selected has a check-in date that
825is closest to, but not after the date given.
826.IP "\fIName based selection\fR"
827.sp 0
828The most powerful selection function is based on assigning symbolic
829names to revisions and branches.
830In large systems, a single release number or date is not sufficient
831to collect the appropriate revisions from all groups.
832For example, suppose one wishes to combine release 2
833of one subsystem and release 15 of another.
834Most likely, the creation dates of those releases differ also.
835Thus, a single revision number or date passed to the \fIco\fR command
836will not suffice to select the right revisions.
837Symbolic revision numbers solve this problem.
838Each RCS file may contain a set of symbolic names that are mapped
839to numeric revision numbers. For example, assume
840the symbol \fIV3\fR is bound to release number 2 in file \fIs,v\fR, and to
841revision number 15.9 in \fIt,v\fR.
842Then the single command
843.D(
844co \-rV3 s,v t,v
845.D)
846retrieves the latest revision of release 2 from \fIs,v\fR,
847and revision 15.9 from \fIt,v\fR.
848In a large system with many modules, checking out all
849revisions with one command greatly simplifies configuration management.
850.PP
851Judicious use of symbolic revision numbers helps with organizing
852large configurations.
853A special command, \fIrcsfreeze\fR,
854assigns a symbolic revision number to a selected revision
855in every RCS file.
856\fIRcsfreeze\fR effectively freezes a configuration.
857The assigned symbolic revision number selects all components
858of the configuration.
859If necessary, symbolic numbers
860may even be intermixed with numeric ones. Thus, \fIV3.5\fR in the
861above example
862would select revision 2.5 in \fIs,v\fR and branch 15.9.5 in \fIt,v\fR.
863.PP
864The options \fI\-r\fR, \fI\-s\fR, \fI\-w\fR and \fI\-d\fR
865may be combined. If a branch is given, the latest revision
866on that branch satisfying all conditions is retrieved;
867otherwise, the default branch is used.
868.NH 2
869Combining MAKE and RCS
870.PP
871MAKE\u1\d
872is a program that processes configurations.
873It is driven by configuration specifications
874recorded in a special file, called a `Makefile'.
875MAKE avoids redundant processing steps
876by comparing creation dates of source and processed objects.
877For example, when instructed to compile all
878modules of a given system, it only recompiles
879those source modules that were changed
880since they were processed last.
881.PP
882MAKE has been extended with an auto-checkout feature for RCS.*
883.FS *
884This auto-checkout extension is available only in some versions of MAKE,
885e.g. GNU MAKE.
886.FE
887When a certain file to be processed is not present,
888MAKE attempts a check-out operation.
889If successful, MAKE performs the required processing, and then deletes
890the checked out file to conserve space.
891The selection parameters discussed above can be passed to MAKE
892either as parameters, or directly embedded in the Makefile.
893MAKE has also been extended to search the subdirectory named \fIRCS\fR
894for needed files, rather than just the current working directory.
895However, if a working file is present, MAKE totally ignores the corresponding
896RCS file and uses the working file.
897(In newer versions of MAKE distributed by AT&T and others,
898auto-checkout can be
899achieved with the rule DEFAULT, instead of a special extension of MAKE.
900However, a file checked out by the rule DEFAULT
901will not be deleted after processing. \fIRcsclean\fR can be
902used for that purpose.)
903.PP
904With auto-checkout, RCS/MAKE can effect a selection rule
905especially tuned for multi-person software development and maintenance.
906In these situations,
907programmers should obtain configurations that consist of
908the revisions they have personally checked out plus the latest
909checked in revision of all other revision groups.
910This schema can be set up as follows.
911.PP
912Each programmer chooses a working directory
913and places into it a symbolic link, named \fIRCS\fR,
914to the directory containing the relevant RCS files.
915The symbolic link makes sure that \fIco\fR and \fIci\fR
916operations need only specify the working files, and that
917the Makefile need not be changed.
918The programmer then checks out the needed files and modifies them.
919If MAKE is invoked,
920it composes configurations by selecting those
921revisions that are checked out, and the rest from the
922subdirectory \fIRCS\fR.
923The latter selection may be controlled by a symbolic
924revision number or any of the other selection criteria.
925If there are several programmers editing in separate working directories,
926they are insulated from each other's changes until checking in their
927modifications.
928.PP
929Similarly, a maintainer can recreate an older configuration
930by starting to work in an empty working directory.
931During the initial MAKE invocation, all revisions are selected from RCS files.
932As the maintainer checks out files and modifies them,
933a new configuration is gradually built up.
934Every time MAKE is invoked, it substitutes the modified revisions
935into the configuration being manipulated.
936.PP
937A final application of RCS is to use it for storing Makefiles.
938Revision groups of Makefiles represent
939multiple versions of configurations.
940Whenever a configuration is baselined or distributed,
941the best approach is to unambiguously fix
942the configuration with a symbolic revision number by calling
943\fIrcsfreeze\fR,
944to embed that symbol into the Makefile, and to
945check in the Makefile (using the same symbolic revision number).
946With this approach, old configurations
947can be regenerated easily and reliably.
948.NH
949Usage Statistics
950.PP
951The following usage statistics were collected on two DEC VAX-11/780
952computers of the Purdue Computer Science Department. Both machines
953are mainly used for research purposes. Thus, the data
954reflect an environment in which the majority of projects
955involve prototyping and advanced software development,
956but relatively little long-term maintenance.
957.PP
958For the first experiment,
959the \fIci\fR and \fIco\fR operations were instrumented
960to log the number of backward and forward deltas applied.
961The data were collected during a 13 month period
962from Dec. 1982 to Dec. 1983.
963Table I summarizes the results.
964.sp 0
965.nr VS 12p
966.vs 12p
967.TS
968center,box,tab(#);
969c|c|c|c|c s|c s
970c|c|c|c|c s|c s
971l|n|n|n|n n|n n.
972Operation#Total#Total deltas#Mean deltas#Operations#Branch
973 #operations #applied#applied#with >1 delta#operations
974_
975co # 7867# 9320#1.18#509#(6%)#203#(3%)
976ci # 3468# 2207#0.64# 85#(2%)# 75#(2%)
977ci & co#11335#11527#1.02#594#(5%)#278#(2%)
978.TE
979.ce 1
980Table I. Statistics for \fIco\fR and \fIci\fR operations.
981.nr VS 18p
982.vs 18p
983.PP
984The first two lines show statistics for check-out and check-in;
985the third line shows the combination.
986Recall that \fIci\fR performs an implicit check-out to obtain
987a revision for computing the delta.
988In all measures presented, the most recent revision (stored intact)
989counts as one delta. The number of deltas applied represents
990the number of passes necessary, where the first `pass' is a copying step.
991.PP
992Note that the check-out operation is executed more than
993twice as frequently as the check-in operation.
994The fourth column gives the mean number of deltas
995applied in all three cases.
996For \fIci\fR, the mean number of deltas applied is less
997than one.
998The reasons are that the initial check-in requires no delta at all, and that
999the only time \fIci\fR requires more than one delta is for branches.
1000Column 5 shows the actual number of operations that applied more than one
1001delta.
1002The last column indicates that branches were not used often.
1003.PP
1004The last three columns demonstrate that the most recent trunk revision
1005is by far the most frequently accessed.
1006For RCS, check-out of
1007this revision is a simple copy operation, which is the absolute minimum
1008given the copy-semantics of \fIco\fR.
1009Access to older revisions and branches
1010is more common in non-academic environments,
1011yet even if access to older deltas were an order
1012of magnitude more frequent,
1013the combined average number of deltas applied would still be below 1.2.
1014Since RCS is faster than SCCS until up to 10 delta applications,
1015reverse deltas are clearly the method of choice.
1016.PP
1017The second experiment, conducted in March of 1984,
1018involved surveying the existing RCS files
1019on our two machines. The goal was to determine the mean number of
1020revisions per RCS file, as well as the space consumed by them.
1021Table II shows the results. (Tables I and II were produced at different
1022times and are unrelated.)
1023.sp 0
1024.nr VS 12p
1025.vs 12p
1026.TS
1027center,box,tab(#);
1028c | c | c | c | c | c | c
1029c | c | c | c | c | c | c
1030l | n | n | n | n | n | n.
1031 #Total RCS#Total#Mean#Mean size of#Mean size of#Overhead
1032 #files#revisions#revisions#RCS files#revisions
1033_
1034All files #8033#11133#1.39#6156#5585#1.10
1035Files with#1477# 4578#3.10#8074#6041#1.34
1036\(>= 2 deltas
1037.TE
1038.ce 1
1039Table II. Statistics for RCS files.
1040.nr VS 18p
1041.vs 18p
1042.PP
1043The mean number of revisions per RCS file is 1.39.
1044Columns 5 and 6 show the mean sizes (in bytes) of an RCS file
1045and of the latest revision of each RCS file, respectively.
1046The `overhead' column contains the ratio of the mean sizes.
1047Assuming that all revisions in an RCS file are approximately the same size,
1048this ratio gives a measure of the space consumed by the extra revisions.
1049.PP
1050In our sample, over 80 per cent of the RCS files contained only a single revision.
1051The reason is that our
1052systems programmers routinely check in all source files
1053on the distribution tapes, even though they may never touch them again.
1054To get a better indication of how much space savings are possible
1055with deltas, all measures with those files
1056that contained 2 or more revisions were recomputed. Only for those files
1057is RCS necessary.
1058As shown in the second line, the average number of revisions for those files is
10593.10, with an overhead of 1.34. This means that the extra 2.10 deltas
1060require 34 per cent extra space, or
106116 per cent per extra revision.
1062Rochkind\u3\d
1063measured the space consumed by SCCS, and
1064reported an average of 5 revisions per group
1065and an overhead of 1.37 (or about 9 per cent per extra revision).
1066In a later paper, Glasser\u6\d
1067observed an average of 7 revisions per group in a single, large project,
1068but provided no overhead figure.
1069In his paper on DSEE\u5\d,
1070Leblang reported that delta storage combined with blank compression
1071results in an overhead of a mere 1\-2 per cent per revision.
1072Since leading blanks accounted for about 20 per cent of the surveyed Pascal
1073programs, a revision group with 5\-10 members was smaller
1074than a single cleartext copy.
1075.PP
1076The above observations demonstrate clearly that the space needed
1077for extra revisions is small. With delta storage, the luxury of
1078keeping multiple revisions online is certainly affordable.
1079In fact, introducing a system with delta storage may reduce
1080storage requirements, because programmers often save back-up copies
1081anyway. Since back-up copies are stored much more efficiently with deltas,
1082introducing a system such as RCS may
1083actually free a considerable amount of space.
1084.NH
1085Survey of Version Control Tools
1086.PP
1087The need to keep back-up copies of software arose when
1088programs and data were no longer stored on paper media, but were entered
1089from terminals and stored on disk.
1090Back-up copies are desirable for reliability, and many modern editors
1091automatically save a back-up copy for every file touched.
1092This strategy
1093is valuable for short-term back-ups, but not suitable for long-term
1094version control, since an existing back-up copy is overwritten whenever the
1095corresponding file is edited.
1096.PP
1097Tape archives are suitable for long-term, offline storage.
1098If all changed files are dumped on a back-up tape once per day, old revisions
1099remain accessible. However, tape archives are unsatisfactory
1100for version control in several ways. First, backing up the file
1101system every 24 hours does not capture intermediate revisions.
1102Secondly, the old revisions are not online,
1103and accessing them is tedious and time-consuming.
1104In particular, it is impractical to
1105compare several old revisions of a group,
1106because that may require mounting and searching several tapes.
1107Tape archives are important fail-safe tools in the
1108event of catastrophic disk failures or accidental deletions,
1109but they are ill-suited for version control.
1110Conversely, version control tools do not obviate the
1111need for tape archives.
1112.PP
1113A natural technique for keeping several old revisions online is
1114to never delete a file.
1115Editing a file
1116simply creates a new file with the same
1117name, but with a different sequence number.
1118This technique, available as an option in DEC's VMS operating system,
1119turns out to be inadequate for version control.
1120First, it is prohibitively expensive in terms of storage costs,
1121especially since no data compression techniques are employed.
1122Secondly, indiscriminately storing every change produces too many
1123revisions, and programmers have difficulties distinguishing them.
1124The proliferation of revisions forces programmers to spend much time on
1125finding and deleting useless files.
1126Thirdly, most of the support functions like locking, logging,
1127revision selection,
1128and identification described in this paper are not available.
1129.PP
1130An alternative approach is to separate editing from revision control.
1131The user may repeatedly edit a given revision,
1132until freezing it with an explicit command.
1133Once a revision is frozen, it is stored permanently and can no longer be modified.
1134(In RCS, freezing a revisions is done with \fIci\fR.)
1135Editing a frozen revision implicitly creates a new one, which
1136can again be changed repeatedly until it is frozen itself.
1137This approach saves exactly those revisions that the user
1138considers important, and keeps the number of revisions manageable.
1139IBM's CLEAR/CASTER\u7\d,
1140AT&T's SCCS\u3\d,
1141CMU's SDC\u8\d
1142and DEC's CMS\u9\d,
1143are examples of version control systems using this approach.
1144CLEAR/CASTER maintains a data base of programs, specifications,
1145documentation and messages, using deltas.
1146Its goal is to provide control over the development process from a
1147management viewpoint.
1148SCCS stores multiple revisions of source text in an ancestral tree,
1149records a log entry for each revision,
1150provides access control, and has facilities
1151for uniquely identifying each revision.
1152An efficient delta technique
1153reduces the space consumed by each revision group.
1154SDC is much simpler than SCCS because it stores not more than
1155two revisions. However, it maintains a complete log for all old
1156revisions, some of which may be on back-up tape.
1157CMS, like SCCS, manages tree-structured revision groups,
1158but offers no identification mechanism.
1159.PP
1160Tools for dealing with configurations are still in a state of flux.
1161SCCS, SDC and CMS can be combined with MAKE or MAKE-like programs.
1162Since flexible selection rules are missing from all these tools,
1163it is sometimes difficult
1164to specify precisely which revision of each group
1165should be passed to MAKE for building a desired configuration.
1166The Xerox Cedar system\u10\d
1167provides a `System Modeller' that can rebuild
1168a configuration from an arbitrary set of module revisions.
1169The revisions of a module are only distinguished by creation time,
1170and there is no tool for managing groups.
1171Since the selection rules are primitive,
1172the System Modeller appears to be somewhat tedious to use.
1173Apollo's DSEE\u5\d
1174is a sophisticated software engineering environment.
1175It manages revision groups in a way similar to SCCS and CMS. Configurations
1176are built using `configuration threads'.
1177A configuration thread states which revision of each group
1178named in a configuration should be chosen.
1179A configuration thread may contain dynamic specifiers
1180(e.g., `choose the revisions I am currently working on,
1181and the most recent revisions otherwise'), which are bound
1182automatically at build time.
1183It also provides a notification mechanism for alerting
1184maintainers about the need to rebuild a system after a change.
1185.PP
1186RCS is based on a general model for describing
1187multi-version/multi-configuration systems\u11\d.
1188The model describes systems using AND/OR graphs, where AND nodes represent
1189configurations, and OR nodes represent version groups.
1190The model gives rise to a suit of selection rules for
1191composing configurations, almost all of which are implemented in RCS.
1192The revisions selected by RCS are passed to MAKE for configuration building.
1193Revision group management is modelled after SCCS.
1194RCS retains SCCS's best features,
1195but offers a significantly simpler user interface,
1196flexible selection rules, adequate integration with MAKE
1197and improved identification.
1198A detailed comparison of RCS and SCCS appears in Reference 4.
1199.PP
1200An important component of all revision control systems
1201is a program for computing deltas.
1202SCCS and RCS use the program \fIdiff\fR\u2\d,
1203which first computes the longest common substring of two
1204revisions, and then produces the delta from that substring.
1205The delta is simply an edit script consisting of deletion and
1206insertion commands that generate one revision from the other.
1207.PP
1208A delta based on a longest common substring is not necessarily minimal,
1209because it does not take advantage of crossing block moves.
1210Crossing block moves arise if two or more blocks of lines
1211(e.g., procedures)
1212appear in a different order in two revisions.
1213An edit script derived from a longest common substring
1214first deletes the shorter of the two blocks, and then reinserts it.
1215Heckel\u12\d
1216proposed an algorithm for detecting block moves, but
1217since the algorithm is based on heuristics,
1218there are conditions
1219under which the generated delta is far from minimal.
1220DSEE uses this algorithm combined with blank compression,
1221apparently with satisfactory overall results.
1222A new algorithm that is guaranteed to produce a minimal delta based on
1223block moves appears in Reference 13.
1224A future release of RCS will use this algorithm.
1225.PP
1226\fIAcknowledgements\fR:
1227Many people have helped make RCS a success by contributed criticisms, suggestions,
1228corrections, and even whole new commands (including manual pages).
1229The list of people is too long to be
1230reproduced here, but my sincere thanks for their help and
1231goodwill goes to all of them.
1232.sp
1233.nr VS 12p
1234.vs 12p
1235.SH
1236Appendix: Synopsis of RCS Operations
1237.LP
1238.IP "\fIci\fP \fB\- check in revisions\fP"
1239.sp 0
1240\fICi\fR stores the contents of a working file into the
1241corresponding RCS file as a new revision.
1242If the RCS file doesn't exist, \fIci\fR creates it.
1243\fICi\fR removes the working file, unless one of the options
1244\fI\-u\fR or \fI\-l\fR is present.
1245For each check-in, \fIci\fR asks for a commentary
1246describing the changes relative to the previous revision.
1247.sp 1
1248\fICi\fR assigns the revision number given by the \fI\-r\fR option;
1249if that option is missing, it derives the number from the
1250lock held by the user; if there is no lock and locking is not strict,
1251\fIci\fR increments the number of the latest revision on the trunk.
1252A side branch can only be started by explicitly specifying its
1253number with the \fI\-r\fR option during check-in.
1254.sp 1
1255\fICi\fR also determines
1256whether the revision to be checked in is different from the
1257previous one, and asks whether to proceed if not.
1258This facility simplifies check-in operations for large systems,
1259because one need not remember which files were changed.
1260.sp 1
1261The option \fI\-k\fR searches the checked in file for identification
1262markers containing
1263the attributes
1264revision number, check-in date, author and state, and assigns these
1265to the new revision rather than computing them. This option is
1266useful for software distribution: Recipients of distributed software
1267using RCS should check in updates with the \fI\-k\fR option.
1268This convention guarantees that revision numbers, check-in dates,
1269etc., are the same at all sites.
1270.IP "\fIco\fP \fB\- check out revisions\fP"
1271.sp 0
1272\fICo\fR retrieves revisions according to revision number,
1273date, author and state attributes. It either places the revision
1274into the working file, or prints it on the standard output.
1275\fICo\fR always expands the identification markers.
1276.IP "\fIident\fP \fB\- extract identification markers\fP"
1277.sp 0
1278\fIIdent\fR extracts the identification markers expanded by \fIco\fR
1279from any file and prints them.
1280.IP "\fIrcs\fP \fB\- change RCS file attributes\fP"
1281.sp 0
1282\fIRcs\fR is an administrative operation that changes access lists,
1283locks, unlocks, breaks locks, toggles the strict-locking feature,
1284sets state attributes and symbolic revision numbers, changes the
1285description, and deletes revisions. A revision can
1286only be deleted if it is not the fork of a side branch.
|