@DATABASE RCS-Docs @$VER: RCS.GUIDE 5.9 (17.5.97) @REMARK Along lines of previous ideas of Hans-Joachim Widmaier, @REMARK these are the reworked RCS 5.7 docs. @author Walter F. Tichy et al, AmigaGuide translation by HWG @REMARK @toc Main @NODE Main "Revision Control System" @{b}RCS 5.7 - Revision Control System 5.7 for the Amiga ***************************************************@{ub} @{" RCSINTRO " link RCSINTRO } introduction to RCS commands Commands: @{" CI " link CI } check in RCS revisions @{" CO " link CO } check out RCS revisions @{" IDENT " link IDENT } identify files @{" MERGE " link MERGE } three-way file merge @{" RCS " link RCS } change RCS file attributes @{" RCSCLEAN " link RCSCLEAN } clean up working files @{" RCSDIFF " link RCSDIFF } compare RCS revisions @{" RCSFREEZE " link RCSFREEZE} freeze a configuration of sources checked in under RCS @{" RCSMERGE " link RCSMERGE } merge RCS revisions @{" RLOG " link RLOG } print log messages and other information about RCS files File format: @{" RCSFILE " link RCSFILE } format of RCS file @ENDNODE @NODE RCSINTRO "RCSINTRO" @{b}NAME@{ub} rcsintro - introduction to RCS commands @{b}DESCRIPTION@{ub} The Revision Control System (RCS) manages multiple revi- sions of files. RCS automates the storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised frequently, for example programs, documentation, graphics, papers, and form let- ters. The basic user interface is extremely simple. The novice only needs to learn two commands: @{b}@{"ci" link CI}@{ub} and @{b}@{"co" link CO}@{ub}. @{b}ci@{ub}, short for "check in", deposits the contents of a file into an archival file called an RCS file. An RCS file contains all revisions of a particular file. @{b}co@{ub}, short for "check out", retrieves revisions from an RCS file. @{b}Functions@{ub} @{b}of@{ub} @{b}RCS@{ub} · Store and retrieve multiple revisions of text. RCS saves all old revisions in a space efficient way. Changes no longer destroy the original, because the previous revisions remain accessible. Revisions can be retrieved according to ranges of revision numbers, symbolic names, dates, authors, and states. · Maintain a complete history of changes. RCS logs all changes automatically. Besides the text of each revision, RCS stores the author, the date and time of check-in, and a log message summarizing the change. The logging makes it easy to find out what happened to a module, without having to compare source listings or having to track down colleagues. · Resolve access conflicts. When two or more pro- grammers wish to modify the same revision, RCS alerts the programmers and prevents one modifica- tion from corrupting the other. · Maintain a tree of revisions. RCS can maintain separate lines of development for each module. It stores a tree structure that represents the ances- tral relationships among revisions. · Merge revisions and resolve conflicts. Two sepa- rate lines of development of a module can be coa- lesced by merging. If the revisions to be merged affect the same sections of code, RCS alerts the user about the overlapping changes. · Control releases and configurations. Revisions can be assigned symbolic names and marked as released, stable, experimental, etc. With these facilities, configurations of modules can be described simply and directly. · Automatically identify each revision with name, revision number, creation time, author, etc. The identification is like a stamp that can be embedded at an appropriate place in the text of a revision. The identification makes it simple to determine which revisions of which modules make up a given configuration. · Minimize secondary storage. RCS needs little extra space for the revisions (only the differences). If intermediate revisions are deleted, the correspond- ing deltas are compressed accordingly. @{b}Getting@{ub} @{b}Started@{ub} @{b}with@{ub} @{b}RCS@{ub} Suppose you have a file @{b}f.c@{ub} that you wish to put under control of RCS. If you have not already done so, make an RCS directory with the command @{b}mkdir@{ub} @{b}RCS@{ub} Then invoke the check-in command @{b}ci@{ub} @{b}f.c@{ub} This command creates an RCS file in the @{b}RCS@{ub} directory, stores @{b}f.c@{ub} into it as revision 1.1, and deletes @{b}f.c@{ub}. It also asks you for a description. The description should be a synopsis of the contents of the file. All later check-in commands will ask you for a log entry, which should summarize the changes that you made. Files in the RCS directory are called RCS files; the oth- ers are called working files. To get back the working file @{b}f.c@{ub} in the previous example, use the check-out com- mand @{b}co@{ub} @{b}f.c@{ub} This command extracts the latest revision from the RCS file and writes it into @{b}f.c@{ub}. If you want to edit @{b}f.c@{ub}, you must lock it as you check it out with the command @{b}co@{ub} @{b}-l@{ub} @{b}f.c@{ub} You can now edit @{b}f.c@{ub}. Suppose after some editing you want to know what changes that you have made. The command @{b}rcsdiff@{ub} @{b}f.c@{ub} tells you the difference between the most recently checked-in version and the working file. You can check the file back in by invoking @{b}ci@{ub} @{b}f.c@{ub} This increments the revision number properly. If @{b}ci@{ub} complains with the message @{b}ci@{ub} @{b}error:@{ub} @{b}no@{ub} @{b}lock@{ub} @{b}set@{ub} @{b}by@{ub} @{u}your@{uu} @{u}name@{uu} then you have tried to check in a file even though you did not lock it when you checked it out. Of course, it is too late now to do the check-out with locking, because another check-out would overwrite your modifications. Instead, invoke @{b}rcs@{ub} @{b}-l@{ub} @{b}f.c@{ub} This command will lock the latest revision for you, unless somebody else got ahead of you already. In this case, you'll have to negotiate with that person. Locking assures that you, and only you, can check in the next update, and avoids nasty problems if several people work on the same file. Even if a revision is locked, it can still be checked out for reading, compiling, etc. All that locking prevents is a @{u}check-in@{uu} by anybody but the locker. If your RCS file is private, i.e., if you are the only person who is going to deposit revisions into it, strict locking is not needed and you can turn it off. If strict locking is turned off, the owner of the RCS file need not have a lock for check-in; all others still do. Turning strict locking off and on is done with the commands @{b}rcs@{ub} @{b}-U@{ub} @{b}f.c@{ub} and @{b}rcs@{ub} @{b}-L@{ub} @{b}f.c@{ub} If you don't want to clutter your working directory with RCS files, create a subdirectory called @{b}RCS@{ub} in your work- ing directory, and move all your RCS files there. RCS commands will look first into that directory to find needed files. All the commands discussed above will still work, without any modification. (Actually, pairs of RCS and working files can be specified in three ways: (a) both are given, (b) only the working file is given, (c) only the RCS file is given. Both RCS and working files may have arbitrary path prefixes; RCS commands pair them up intelligently.) To avoid the deletion of the working file during check-in (in case you want to continue editing or compiling), invoke @{b}ci@{ub} @{b}-l@{ub} @{b}f.c@{ub} or @{b}ci@{ub} @{b}-u@{ub} @{b}f.c@{ub} These commands check in @{b}f.c@{ub} as usual, but perform an implicit check-out. The first form also locks the checked in revision, the second one doesn't. Thus, these options save you one check-out operation. The first form is use- ful if you want to continue editing, the second one if you just want to read the file. Both update the identifica- tion markers in your working file (see below). You can give @{b}ci@{ub} the number you want assigned to a checked in revision. Assume all your revisions were numbered 1.1, 1.2, 1.3, etc., and you would like to start release 2. The command @{b}ci@{ub} @{b}-r2@{ub} @{b}f.c@{ub} or @{b}ci@{ub} @{b}-r2.1@{ub} @{b}f.c@{ub} assigns the number 2.1 to the new revision. From then on, @{b}ci@{ub} will number the subsequent revisions with 2.2, 2.3, etc. The corresponding @{b}co@{ub} commands @{b}co@{ub} @{b}-r2@{ub} @{b}f.c@{ub} and @{b}co@{ub} @{b}-r2.1@{ub} @{b}f.c@{ub} retrieve the latest revision numbered 2.@{u}x@{uu} and the revision 2.1, respectively. @{b}co@{ub} without a revision number selects the latest revision on the @{u}trunk@{uu}, i.e. the highest revi- sion with a number consisting of two fields. Numbers with more than two fields are needed for branches. For exam- ple, to start a branch at revision 1.3, invoke @{b}ci@{ub} @{b}-r1.3.1@{ub} @{b}f.c@{ub} This command starts a branch numbered 1 at revision 1.3, and assigns the number 1.3.1.1 to the new revision. For more information about branches, see @{b}@{"rcsfile" link RCSFILE}@{ub}. @{b}Automatic@{ub} @{b}Identification@{ub} RCS can put special strings for identification into your source and object code. To obtain such identification, place the marker @{b}$Id$@{ub} into your text, for instance inside a comment. RCS will replace this marker with a string of the form @{b}$Id:@{ub} @{u}filename@{uu} @{u}revision@{uu} @{u}date@{uu} @{u}time@{uu} @{u}author@{uu} @{u}state@{uu} @{b}$@{ub} With such a marker on the first page of each module, you can always see with which revision you are working. RCS keeps the markers up to date automatically. To propagate the markers into your object code, simply put them into literal character strings. In C, this is done as follows: @{b}static@{ub} @{b}char@{ub} @{b}rcsid[]@{ub} @{b}=@{ub} @{b}"$Id$";@{ub} The command @{b}ident@{ub} extracts such markers from any file, even object code and dumps. Thus, @{b}ident@{ub} lets you find out which revisions of which modules were used in a given pro- gram. You may also find it useful to put the marker @{b}$Log$@{ub} into your text, inside a comment. This marker accumulates the log messages that are requested during check-in. Thus, you can maintain the complete history of your file directly inside it. There are several additional identi- fication markers; see @{b}@{"co" link CO}@{ub} for details. @{b}IDENTIFICATION@{ub} Author: Walter F. Tichy. Manual Page Revision: 5.3; Release Date: 1993/11/03. Copyright (C) 1982, 1988, 1989 Walter F. Tichy. Copyright (C) 1990, 1991, 1992, 1993 Paul Eggert. @{b}SEE@{ub} @{b}ALSO@{ub} @{"ci" link CI}, @{"co" link CO}, @{"ident" link IDENT}, @{"rcs" link RCS}, @{"rcsdiff" link RCSDIFF}, @{"rcsintro" link RCSINTRO}, @{"rcsmerge" link RCSMERGE}, @{"rlog" link RLOG} Walter F. Tichy, RCS--A System for Version Control, @{u}Software--Practice@{uu} @{u}&@{uu} @{u}Experience@{uu} @{b}15@{ub}, 7 (July 1985), 637-654. @ENDNODE @NODE CI "CI" @{b}NAME@{ub} ci - check in RCS revisions @{b}SYNOPSIS@{ub} @{b}ci@{ub} [@{u}options@{uu}] @{u}file@{uu} ... @{b}DESCRIPTION@{ub} @{b}ci@{ub} stores new revisions into RCS files. Each pathname matching an RCS suffix is taken to be an RCS file. All others are assumed to be working files containing new revisions. @{b}ci@{ub} deposits the contents of each working file into the corresponding RCS file. If only a working file is given, @{b}ci@{ub} tries to find the corresponding RCS file in an RCS subdirectory and then in the working file's direc- tory. For more details, see FILE NAMING below. For @{b}ci@{ub} to work, the caller's login must be on the access list, except if the access list is empty or the caller is the superuser or the owner of the file. To append a new revision to an existing branch, the tip revision on that branch must be locked by the caller. Otherwise, only a new branch can be created. This restriction is not enforced for the owner of the file if non-strict locking is used (see @{b}@{"rcs" link RCS}@{ub}). A lock held by someone else can be broken with the @{b}rcs@{ub} command. Unless the @{b}-f@{ub} option is given, @{b}ci@{ub} checks whether the revi- sion to be deposited differs from the preceding one. If not, instead of creating a new revision @{b}ci@{ub} reverts to the preceding one. To revert, ordinary @{b}ci@{ub} removes the working file and any lock; @{b}ci@{ub} @{b}-l@{ub} keeps and @{b}ci@{ub} @{b}-u@{ub} removes any lock, and then they both generate a new working file much as if @{b}co@{ub} @{b}-l@{ub} or @{b}co@{ub} @{b}-u@{ub} had been applied to the preceding revision. When reverting, any @{b}-n@{ub} and @{b}-s@{ub} options apply to the preced- ing revision. For each revision deposited, @{b}ci@{ub} prompts for a log message. The log message should summarize the change and must be terminated by end-of-file or by a line containing @{b}.@{ub} by itself. If several files are checked in @{b}ci@{ub} asks whether to reuse the previous log message. If the standard input is not a terminal, @{b}ci@{ub} suppresses the prompt and uses the same log message for all files. See also @{b}-m@{ub}. If the RCS file does not exist, @{b}ci@{ub} creates it and deposits the contents of the working file as the initial revision (default number: @{b}1.1@{ub}). The access list is initialized to empty. Instead of the log message, @{b}ci@{ub} requests descrip- tive text (see @{b}-t@{ub} below). The number @{u}rev@{uu} of the deposited revision can be given by any of the options @{b}-f@{ub}, @{b}-i@{ub}, @{b}-I@{ub}, @{b}-j@{ub}, @{b}-k@{ub}, @{b}-l@{ub}, @{b}-M@{ub}, @{b}-q@{ub}, @{b}-r@{ub}, or @{b}-u@{ub}. @{u}rev@{uu} can be symbolic, numeric, or mixed. Symbolic names in @{u}rev@{uu} must already be defined; see the @{b}-n@{ub} and @{b}-N@{ub} options for assigning names during checkin. If @{u}rev@{uu} is @{b}$@{ub}, @{b}ci@{ub} determines the revision number from keyword values in the working file. If @{u}rev@{uu} begins with a period, then the default branch (nor- mally the trunk) is prepended to it. If @{u}rev@{uu} is a branch number followed by a period, then the latest revision on that branch is used. If @{u}rev@{uu} is a revision number, it must be higher than the latest one on the branch to which @{u}rev@{uu} belongs, or must start a new branch. If @{u}rev@{uu} is a branch rather than a revision number, the new revision is appended to that branch. The level number is obtained by incrementing the tip revision number of that branch. If @{u}rev@{uu} indicates a non-existing branch, that branch is created with the initial revision numbered @{u}rev@{b}.1@{ub}@{uu}. If @{u}rev@{uu} is omitted, @{b}ci@{ub} tries to derive the new revision number from the caller's last lock. If the caller has locked the tip revision of a branch, the new revision is appended to that branch. The new revision number is obtained by incrementing the tip revision number. If the caller locked a non-tip revision, a new branch is started at that revision by incrementing the highest branch number at that revision. The default initial branch and level numbers are @{b}1@{ub}. If @{u}rev@{uu} is omitted and the caller has no lock, but owns the file and locking is not set to @{u}strict@{uu}, then the revision is appended to the default branch (normally the trunk; see the @{b}-b@{ub} option of @{b}@{"rcs" link RCS}@{ub}). Exception: On the trunk, revisions can be appended to the end, but not inserted. @{b}OPTIONS@{ub} @{b}-r@{u}rev@{ub}@{uu} Check in revision @{u}rev@{uu}. @{b}-r@{ub} The bare @{b}-r@{ub} option (without any revision) has an unusual meaning in @{b}ci@{ub}. With other RCS commands, a bare @{b}-r@{ub} option specifies the most recent revision on the default branch, but with @{b}ci@{ub}, a bare @{b}-r@{ub} option reestablishes the default behavior of releasing a lock and removing the working file, and is used to override any default @{b}-l@{ub} or @{b}-u@{ub} options established by shell aliases or scripts. @{b}-l@{ub}[@{u}rev@{uu}] works like @{b}-r@{ub}, except it performs an additional @{b}co@{ub} @{b}-l@{ub} for the deposited revision. Thus, the deposited revision is immediately checked out again and locked. This is useful for saving a revision although one wants to continue editing it after the checkin. @{b}-u@{ub}[@{u}rev@{uu}] works like @{b}-l@{ub}, except that the deposited revision is not locked. This lets one read the working file immediately after checkin. The @{b}-l@{ub}, bare @{b}-r@{ub}, and @{b}-u@{ub} options are mutually exclu- sive and silently override each other. For exam- ple, @{b}ci@{ub} @{b}-u@{ub} @{b}-r@{ub} is equivalent to @{b}ci@{ub} @{b}-r@{ub} because bare @{b}-r@{ub} overrides @{b}-u@{ub}. @{b}-f@{ub}[@{u}rev@{uu}] forces a deposit; the new revision is deposited even it is not different from the preceding one. @{b}-k@{ub}[@{u}rev@{uu}] searches the working file for keyword values to determine its revision number, creation date, state, and author (see @{b}@{"co" link CO}@{ub}), and assigns these values to the deposited revision, rather than com- puting them locally. It also generates a default login message noting the login of the caller and the actual checkin date. This option is useful for software distribution. A revision that is sent to several sites should be checked in with the @{b}-k@{ub} option at these sites to preserve the original num- ber, date, author, and state. The extracted key- word values and the default log message can be overridden with the options @{b}-d@{ub}, @{b}-m@{ub}, @{b}-s@{ub}, @{b}-w@{ub}, and any option that carries a revision number. @{b}-q@{ub}[@{u}rev@{uu}] quiet mode; diagnostic output is not printed. A revision that is not different from the preceding one is not deposited, unless @{b}-f@{ub} is given. @{b}-i@{ub}[@{u}rev@{uu}] initial checkin; report an error if the RCS file already exists. This avoids race conditions in certain applications. @{b}-j@{ub}[@{u}rev@{uu}] just checkin and do not initialize; report an error if the RCS file does not already exist. @{b}-I@{ub}[@{u}rev@{uu}] interactive mode; the user is prompted and ques- tioned even if the standard input is not a termi- nal. @{b}-d@{ub}[@{u}date@{uu}] uses @{u}date@{uu} for the checkin date and time. The @{u}date@{uu} is specified in free format as explained in @{b}@{"co" link CO}@{ub}. This is useful for lying about the checkin date, and for @{b}-k@{ub} if no date is available. If @{u}date@{uu} is empty, the working file's time of last modification is used. @{b}-M@{ub}[@{u}rev@{uu}] Set the modification time on any new working file to be the date of the retrieved revision. For example, @{b}ci@{ub} @{b}-d@{ub} @{b}-M@{ub} @{b}-u@{ub} @{u}f@{uu} does not alter @{u}f@{uu}'s modifica- tion time, even if @{u}f@{uu}'s contents change due to key- word substitution. Use this option with care; it can confuse @{b}@{i}make@{ui}@{ub}. @{b}-m@{u}msg@{ub}@{uu} uses the string @{u}msg@{uu} as the log message for all revisions checked in. By convention, log messages that start with @{b}#@{ub} are comments and are ignored by programs like GNU Emacs's @{b}vc@{ub} package. Also, log messages that start with @{b}{@{u}clumpname}@{ub}@{uu} (followed by white space) are meant to be clumped together if possible, even if they are associated with differ- ent files; the @{b}{@{u}clumpname}@{ub}@{uu} label is used only for clumping, and is not considered to be part of the log message itself. @{b}-n@{u}name@{ub}@{uu} assigns the symbolic name @{u}name@{uu} to the number of the checked-in revision. @{b}ci@{ub} prints an error message if @{u}name@{uu} is already assigned to another number. @{b}-N@{u}name@{ub}@{uu} same as @{b}-n@{ub}, except that it overrides a previous assignment of @{u}name@{uu}. @{b}-s@{u}state@{ub}@{uu} sets the state of the checked-in revision to the identifier @{u}state@{uu}. The default state is @{b}Exp@{ub}. @{b}-t@{u}file@{ub}@{uu} writes descriptive text from the contents of the named @{u}file@{uu} into the RCS file, deleting the existing text. The @{u}file@{uu} cannot begin with @{b}-@{ub}. @{b}-t-@{u}string@{ub}@{uu} Write descriptive text from the @{u}string@{uu} into the RCS file, deleting the existing text. The @{b}-t@{ub} option, in both its forms, has effect only during an initial checkin; it is silently ignored otherwise. During the initial checkin, if @{b}-t@{ub} is not given, @{b}ci@{ub} obtains the text from standard input, terminated by end-of-file or by a line containing @{b}.@{ub} by itself. The user is prompted for the text if interaction is possible; see @{b}-I@{ub}. For backward compatibility with older versions of RCS, a bare @{b}-t@{ub} option is ignored. @{b}-T@{ub} Set the RCS file's modification time to the new revision's time if the former precedes the latter and there is a new revision; preserve the RCS file's modification time otherwise. If you have locked a revision, @{b}ci@{ub} usually updates the RCS file's modification time to the current time, because the lock is stored in the RCS file and removing the lock requires changing the RCS file. This can create an RCS file newer than the working file in one of two ways: first, @{b}ci@{ub} @{b}-M@{ub} can create a working file with a date before the current time; second, when reverting to the previous revision the RCS file can change while the working file remains unchanged. These two cases can cause excessive recompilation caused by a @{b}@{i}make@{ui}@{ub} dependency of the working file on the RCS file. The @{b}-T@{ub} option inhibits this recompilation by lying about the RCS file's date. Use this option with care; it can suppress recompilation even when a checkin of one working file should affect another working file associated with the same RCS file. For example, suppose the RCS file's time is 01:00, the (changed) working file's time is 02:00, some other copy of the working file has a time of 03:00, and the cur- rent time is 04:00. Then @{b}ci@{ub} @{b}-d@{ub} @{b}-T@{ub} sets the RCS file's time to 02:00 instead of the usual 04:00; this causes @{b}@{i}make@{ui}@{ub} to think (incorrectly) that the other copy is newer than the RCS file. @{b}-w@{u}login@{ub}@{uu} uses @{u}login@{uu} for the author field of the deposited revision. Useful for lying about the author, and for @{b}-k@{ub} if no author is available. @{b}-V@{ub} Print RCS's version number. @{b}-V@{u}n@{ub}@{uu} Emulate RCS version @{u}n@{uu}. See @{b}@{"co" link CO}@{ub} for details. @{b}-x@{u}suffixes@{ub}@{uu} specifies the suffixes for RCS files. A nonempty suffix matches any pathname ending in the suffix. An empty suffix matches any pathname of the form @{b}RCS/@{u}path@{ub}@{uu} or @{u}path1@{b}/RCS/path2.@{ub}@{uu} The @{b}-x@{ub} option can specify a list of suffixes separated by @{b}/@{ub}. For example, @{b}-x,v/@{ub} specifies two suffixes: @{b},v@{ub} and the empty suffix. If two or more suffixes are speci- fied, they are tried in order when looking for an RCS file; the first one that works is used for that file. If no RCS file is found but an RCS file can be created, the suffixes are tried in order to determine the new RCS file's name. The default for @{u}suffixes@{uu} is installation-dependent; normally it is @{b},v/@{ub} for hosts like Unix that permit commas in file- names, and is empty (i.e. just the empty suffix) for other hosts. @{b}-z@{u}zone@{ub}@{uu} specifies the date output format in keyword substi- tution, and specifies the default time zone for @{u}date@{uu} in the @{b}-d@{u}date@{ub}@{uu} option. The @{u}zone@{uu} should be empty, a numeric UTC offset, or the special string @{b}LT@{ub} for local time. The default is an empty @{u}zone@{uu}, which uses the traditional RCS format of UTC with- out any time zone indication and with slashes sepa- rating the parts of the date; otherwise, times are output in ISO 8601 format with time zone indica- tion. For example, if local time is January 11, 1990, 8pm Pacific Standard Time, eight hours west of UTC, then the time is output as follows: @{u}option@{uu} @{u}time@{uu} @{u}output@{uu} @{b}-z@{ub} @{b}1990/01/12@{ub} @{b}04:00:00@{ub} @{u}(default)@{uu} @{b}-zLT@{ub} @{b}1990-01-11@{ub} @{b}20:00:00-08@{ub} @{b}-z+05:30@{ub} @{b}1990-01-12@{ub} @{b}09:30:00+05:30@{ub} The @{b}-z@{ub} option does not affect dates stored in RCS files, which are always UTC. @{b}FILE@{ub} @{b}NAMING@{ub} Pairs of RCS files and working files can be specified in three ways (see also the example section). 1) Both the RCS file and the working file are given. The RCS pathname is of the form @{u}path1@{b}/workfileX@{ub}@{uu} and the work- ing pathname is of the form @{u}path2@{b}/workfile@{ub}@{uu} where @{u}path1@{b}/@{ub}@{uu} and @{u}path2@{b}/@{ub}@{uu} are (possibly different or empty) paths, @{u}work-@{uu} @{u}file@{uu} is a filename, and @{u}X@{uu} is an RCS suffix. If @{u}X@{uu} is empty, @{u}path1@{b}/@{ub}@{uu} must start with @{b}RCS/@{ub} or must contain @{b}/RCS/@{ub}. 2) Only the RCS file is given. Then the working file is created in the current directory and its name is derived from the name of the RCS file by removing @{u}path1@{b}/@{ub}@{uu} and the suffix @{u}X@{uu}. 3) Only the working file is given. Then @{b}ci@{ub} considers each RCS suffix @{u}X@{uu} in turn, looking for an RCS file of the form @{u}path2@{b}/RCS/workfileX@{ub}@{uu} or (if the former is not found and @{u}X@{uu} is nonempty) @{u}path2@{b}/workfileX.@{ub}@{uu} If the RCS file is specified without a path in 1) and 2), @{b}ci@{ub} looks for the RCS file first in the directory @{b}./RCS@{ub} and then in the current directory. @{b}ci@{ub} reports an error if an attempt to open an RCS file fails for an unusual reason, even if the RCS file's path- name is just one of several possibilities. For example, to suppress use of RCS commands in a directory @{u}d@{uu}, create a regular file named @{u}d@{b}/RCS@{ub}@{uu} so that casual attempts to use RCS commands in @{u}d@{uu} fail because @{u}d@{b}/RCS@{ub}@{uu} is not a directory. @{b}EXAMPLES@{ub} Suppose @{b},v@{ub} is an RCS suffix and the current directory con- tains a subdirectory @{b}RCS@{ub} with an RCS file @{b}io.c,v@{ub}. Then each of the following commands check in a copy of @{b}io.c@{ub} into @{b}RCS/io.c,v@{ub} as the latest revision, removing @{b}io.c@{ub}. @{b}ci@{ub} @{b}io.c;@{ub} @{b}ci@{ub} @{b}RCS/io.c,v;@{ub} @{b}ci@{ub} @{b}io.c,v;@{ub} @{b}ci@{ub} @{b}io.c@{ub} @{b}RCS/io.c,v;@{ub} @{b}ci@{ub} @{b}io.c@{ub} @{b}io.c,v;@{ub} @{b}ci@{ub} @{b}RCS/io.c,v@{ub} @{b}io.c;@{ub} @{b}ci@{ub} @{b}io.c,v@{ub} @{b}io.c;@{ub} Suppose instead that the empty suffix is an RCS suffix and the current directory contains a subdirectory @{b}RCS@{ub} with an RCS file @{b}io.c@{ub}. The each of the following commands checks in a new revision. @{b}ci@{ub} @{b}io.c;@{ub} @{b}ci@{ub} @{b}RCS/io.c;@{ub} @{b}ci@{ub} @{b}io.c@{ub} @{b}RCS/io.c;@{ub} @{b}ci@{ub} @{b}RCS/io.c@{ub} @{b}io.c;@{ub} @{b}FILE@{ub} @{b}MODES@{ub} An RCS file created by @{b}ci@{ub} inherits the read and execute permissions from the working file. If the RCS file exists already, @{b}ci@{ub} preserves its read and execute permissions. @{b}ci@{ub} always turns off all write permissions of RCS files. @{b}FILES@{ub} Temporary files are created in the directory containing the working file, and also in the temporary directory (see @{b}TMPDIR@{ub} under @{b}ENVIRONMENT@{ub}). A semaphore file or files are created in the directory containing the RCS file. With a nonempty suffix, the semaphore names begin with the first character of the suffix; therefore, do not specify an suf- fix whose first character could be that of a working file- name. With an empty suffix, the semaphore names end with @{b}_@{ub} so working filenames should not end in @{b}_@{ub}. @{b}ci@{ub} never changes an RCS or working file. Normally, @{b}ci@{ub} unlinks the file and creates a new one; but instead of breaking a chain of one or more symbolic links to an RCS file, it unlinks the destination file instead. Therefore, @{b}ci@{ub} breaks any hard or symbolic links to any working file it changes; and hard links to RCS files are ineffective, but symbolic links to RCS files are preserved. The effective user must be able to search and write the directory containing the RCS file. Normally, the real user must be able to read the RCS and working files and to search and write the directory containing the working file; however, some older hosts cannot easily switch between real and effective users, so on these hosts the effective user is used for all accesses. The effective user is the same as the real user unless your copies of @{b}ci@{ub} and @{b}co@{ub} have setuid privileges. As described in the next section, these privileges yield extra security if the effective user owns all RCS files and directories, and if only the effective user can write RCS directories. Users can control access to RCS files by setting the per- missions of the directory containing the files; only users with write access to the directory can use RCS commands to change its RCS files. For example, in hosts that allow a user to belong to several groups, one can make a group's RCS directories writable to that group only. This approach suffices for informal projects, but it means that any group member can arbitrarily change the group's RCS files, and can even remove them entirely. Hence more for- mal projects sometimes distinguish between an RCS adminis- trator, who can change the RCS files at will, and other project members, who can check in new revisions but cannot otherwise change the RCS files. @{b}SETUID@{ub} @{b}USE@{ub} To prevent anybody but their RCS administrator from delet- ing revisions, a set of users can employ setuid privileges as follows. · Check that the host supports RCS setuid use. Consult a trustworthy expert if there are any doubts. It is best if the @{b}seteuid@{ub} system call works as described in Posix 1003.1a Draft 5, because RCS can switch back and forth easily between real and effective users, even if the real user is @{b}root@{ub}. If not, the second best is if the @{b}setuid@{ub} system call supports saved setuid (the {_POSIX_SAVED_IDS} behavior of Posix 1003.1-1990); this fails only if the real or effective user is @{b}root@{ub}. If RCS detects any failure in setuid, it quits immediately. · Choose a user @{u}A@{uu} to serve as RCS administrator for the set of users. Only @{u}A@{uu} can invoke the @{b}rcs@{ub} command on the users' RCS files. @{u}A@{uu} should not be @{b}root@{ub} or any other user with special powers. Mutually suspicious sets of users should use different administrators. · Choose a pathname @{u}B@{uu} to be a directory of files to be executed by the users. · Have @{u}A@{uu} set up @{u}B@{uu} to contain copies of @{b}ci@{ub} and @{b}co@{ub} that are setuid to @{u}A@{uu} by copying the commands from their standard installation directory @{u}D@{uu} as follows: @{b}mkdir@{ub} @{u}B@{uu} @{b}cp@{ub} @{u}D@{b}/c[io]@{ub}@{uu} @{u}B@{uu} @{b}chmod@{ub} @{b}go-w,u+s@{ub} @{u}B@{b}/c[io]@{ub}@{uu} · Have each user prepend @{u}B@{uu} to their path as follows: @{b}PATH=@{u}B:$PATH;@{ub}@{uu} @{b}export@{ub} @{b}PATH@{ub} # ordinary shell @{b}set@{ub} @{b}path=(@{u}B@{ub}@{uu} @{b}$path)@{ub} # C shell · Have @{u}A@{uu} create each RCS directory @{u}R@{uu} with write access only to @{u}A@{uu} as follows: @{b}mkdir@{ub} @{u}R@{uu} @{b}chmod@{ub} @{b}go-w@{ub} @{u}R@{uu} · If you want to let only certain users read the RCS files, put the users into a group @{u}G@{uu}, and have @{u}A@{uu} further protect the RCS directory as follows: @{b}chgrp@{ub} @{u}G@{uu} @{u}R@{uu} @{b}chmod@{ub} @{b}g-w,o-rwx@{ub} @{u}R@{uu} · Have @{u}A@{uu} copy old RCS files (if any) into @{u}R@{uu}, to ensure that @{u}A@{uu} owns them. · An RCS file's access list limits who can check in and lock revisions. The default access list is empty, which grants checkin access to anyone who can read the RCS file. If you want limit checkin access, have @{u}A@{uu} invoke @{b}rcs@{ub} @{b}-a@{ub} on the file; see @{b}@{"rcs" link RCS}@{ub}. In particular, @{b}rcs@{ub} @{b}-e@{ub} @{b}-a@{u}A@{ub}@{uu} limits access to just @{u}A@{uu}. · Have @{u}A@{uu} initialize any new RCS files with @{b}rcs@{ub} @{b}-i@{ub} before initial checkin, adding the @{b}-a@{ub} option if you want to limit checkin access. · Give setuid privileges only to @{b}ci@{ub}, @{b}co@{ub}, and @{b}rcsclean@{ub}; do not give them to @{b}rcs@{ub} or to any other command. · Do not use other setuid commands to invoke RCS commands; setuid is trickier than you think! @{b}ENVIRONMENT@{ub} @{b}RCSINIT@{ub} options prepended to the argument list, separated by spaces. A backslash escapes spaces within an option. The @{b}RCSINIT@{ub} options are prepended to the argument lists of most RCS commands. Useful @{b}RCSINIT@{ub} options include @{b}-q@{ub}, @{b}-V@{ub}, @{b}-x@{ub}, and @{b}-z@{ub}. @{b}TMPDIR@{ub} Name of the temporary directory. If not set, the environment variables @{b}TMP@{ub} and @{b}TEMP@{ub} are inspected instead and the first value found is taken; if none of them are set, a host-dependent default is used, typically @{b}/tmp@{ub}. @{b}DIAGNOSTICS@{ub} For each revision, @{b}ci@{ub} prints the RCS file, the working file, and the number of both the deposited and the preced- ing revision. The exit status is zero if and only if all operations were successful. @{b}IDENTIFICATION@{ub} Author: Walter F. Tichy. Manual Page Revision: 5.17; Release Date: 1995/06/16. Copyright (C) 1982, 1988, 1989 Walter F. Tichy. Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995 Paul Eggert. @{b}SEE@{ub} @{b}ALSO@{ub} @{"co" link CO}, @{i}emacs@{ui}, @{"ident" link IDENT}, @{i}make@{ui}, @{"rcs" link RCS}, @{"rcsclean" link RCSCLEAN}, @{"rcsdiff" link RCSDIFF}, @{"rcsintro" link RCSINTRO}, @{"rcsmerge" link RCSMERGE}, @{"rlog" link RLOG}, @{i}setuid@{ui}, @{"rcsfile" link RCSFILE} Walter F. Tichy, RCS--A System for Version Control, @{u}Software--Practice@{uu} @{u}&@{uu} @{u}Experience@{uu} @{b}15@{ub}, 7 (July 1985), 637-654. ENDNODE @NODE CO "CO" @{b}NAME@{ub} co - check out RCS revisions @{b}SYNOPSIS@{ub} @{b}co@{ub} [@{u}options@{uu}] @{u}file@{uu} ... @{b}DESCRIPTION@{ub} @{b}co@{ub} retrieves a revision from each RCS file and stores it into the corresponding working file. Pathnames matching an RCS suffix denote RCS files; all others denote working files. Names are paired as explained in @{b}@{"ci" link CI}@{ub}. Revisions of an RCS file can be checked out locked or unlocked. Locking a revision prevents overlapping updates. A revision checked out for reading or processing (e.g., compiling) need not be locked. A revision checked out for editing and later checkin must normally be locked. Checkout with locking fails if the revision to be checked out is currently locked by another user. (A lock can be broken with @{b}@{"rcs" link RCS}@{ub}.) Checkout with locking also requires the caller to be on the access list of the RCS file, unless he is the owner of the file or the superuser, or the access list is empty. Checkout without locking is not subject to accesslist restrictions, and is not affected by the presence of locks. A revision is selected by options for revision or branch number, checkin date/time, author, or state. When the selection options are applied in combination, @{b}co@{ub} retrieves the latest revision that satisfies all of them. If none of the selection options is specified, @{b}co@{ub} retrieves the latest revision on the default branch (normally the trunk, see the @{b}-b@{ub} option of @{b}@{"rcs" link RCS}@{ub}). A revision or branch number can be attached to any of the options @{b}-f@{ub}, @{b}-I@{ub}, @{b}-l@{ub}, @{b}-M@{ub}, @{b}-p@{ub}, @{b}-q@{ub}, @{b}-r@{ub}, or @{b}-u@{ub}. The options @{b}-d@{ub} (date), @{b}-s@{ub} (state), and @{b}-w@{ub} (author) retrieve from a single branch, the @{u}selected@{uu} branch, which is either specified by one of @{b}-f@{ub}, ..., @{b}-u@{ub}, or the default branch. A @{b}co@{ub} command applied to an RCS file with no revisions cre- ates a zero-length working file. @{b}co@{ub} always performs key- word substitution (see below). @{b}OPTIONS@{ub} @{b}-r@{ub}[@{u}rev@{uu}] retrieves the latest revision whose number is less than or equal to @{u}rev@{uu}. If @{u}rev@{uu} indicates a branch rather than a revision, the latest revision on that branch is retrieved. If @{u}rev@{uu} is omitted, the latest revision on the default branch (see the @{b}-b@{ub} option of @{b}@{"rcs" link RCS}@{ub}) is retrieved. If @{u}rev@{uu} is @{b}$@{ub}, @{b}co@{ub} deter- mines the revision number from keyword values in the working file. Otherwise, a revision is com- posed of one or more numeric or symbolic fields separated by periods. If @{u}rev@{uu} begins with a period, then the default branch (normally the trunk) is prepended to it. If @{u}rev@{uu} is a branch number fol- lowed by a period, then the latest revision on that branch is used. The numeric equivalent of a sym- bolic field is specified with the @{b}-n@{ub} option of the commands @{b}@{"ci" link CI}@{ub} and @{b}@{"rcs" link RCS}@{ub}. @{b}-l@{ub}[@{u}rev@{uu}] same as @{b}-r@{ub}, except that it also locks the retrieved revision for the caller. @{b}-u@{ub}[@{u}rev@{uu}] same as @{b}-r@{ub}, except that it unlocks the retrieved revision if it was locked by the caller. If @{u}rev@{uu} is omitted, @{b}-u@{ub} retrieves the revision locked by the caller, if there is one; otherwise, it retrieves the latest revision on the default branch. @{b}-f@{ub}[@{u}rev@{uu}] forces the overwriting of the working file; useful in connection with @{b}-q@{ub}. See also FILE MODES below. @{b}-kkv@{ub} Generate keyword strings using the default form, e.g. @{b}$Revision:@{ub} @{b}5.13@{ub} @{b}$@{ub} for the @{b}Revision@{ub} keyword. A locker's name is inserted in the value of the @{b}Header@{ub}, @{b}Id@{ub}, and @{b}Locker@{ub} keyword strings only as a file is being locked, i.e. by @{b}ci@{ub} @{b}-l@{ub} and @{b}co@{ub} @{b}-l@{ub}. This is the default. @{b}-kkvl@{ub} Like @{b}-kkv@{ub}, except that a locker's name is always inserted if the given revision is currently locked. @{b}-kk@{ub} Generate only keyword names in keyword strings; omit their values. See KEYWORD SUBSTITUTION below. For example, for the @{b}Revision@{ub} keyword, generate the string @{b}$Revision$@{ub} instead of @{b}$Revision:@{ub} @{b}5.13@{ub} @{b}$@{ub}. This option is useful to ignore differences due to keyword substitution when comparing different revi- sions of a file. Log messages are inserted after @{b}$Log$@{ub} keywords even if @{b}-kk@{ub} is specified, since this tends to be more useful when merging changes. @{b}-ko@{ub} Generate the old keyword string, present in the working file just before it was checked in. For example, for the @{b}Revision@{ub} keyword, generate the string @{b}$Revision:@{ub} @{b}1.1@{ub} @{b}$@{ub} instead of @{b}$Revision:@{ub} @{b}5.13@{ub} @{b}$@{ub} if that is how the string appeared when the file was checked in. This can be useful for file for- mats that cannot tolerate any changes to substrings that happen to take the form of keyword strings. @{b}-kb@{ub} Generate a binary image of the old keyword string. This acts like @{b}-ko@{ub}, except it performs all working file input and output in binary mode. This makes little difference on Posix and Unix hosts, but on DOS-like hosts one should use @{b}rcs@{ub} @{b}-i@{ub} @{b}-kb@{ub} to ini- tialize an RCS file intended to be used for binary files. Also, on all hosts, @{b}@{"rcsmerge" link RCSMERGE}@{ub} normally refuses to merge files when @{b}-kb@{ub} is in effect. @{b}-kv@{ub} Generate only keyword values for keyword strings. For example, for the @{b}Revision@{ub} keyword, generate the string @{b}5.13@{ub} instead of @{b}$Revision:@{ub} @{b}5.13@{ub} @{b}$@{ub}. This can help generate files in programming languages where it is hard to strip keyword delimiters like @{b}$Revision:@{ub} @{b}$@{ub} from a string. However, further key- word substitution cannot be performed once the key- word names are removed, so this option should be used with care. Because of this danger of losing keywords, this option cannot be combined with @{b}-l@{ub}, and the owner write permission of the working file is turned off; to edit the file later, check it out again without @{b}-kv@{ub}. @{b}-p@{ub}[@{u}rev@{uu}] prints the retrieved revision on the standard out- put rather than storing it in the working file. This option is useful when @{b}co@{ub} is part of a pipe. @{b}-q@{ub}[@{u}rev@{uu}] quiet mode; diagnostics are not printed. @{b}-I@{ub}[@{u}rev@{uu}] interactive mode; the user is prompted and ques- tioned even if the standard input is not a termi- nal. @{b}-d@{u}date@{ub}@{uu} retrieves the latest revision on the selected branch whose checkin date/time is less than or equal to @{u}date@{uu}. The date and time can be given in free format. The time zone @{b}LT@{ub} stands for local time; other common time zone names are understood. For example, the following @{u}date@{uu}s are equivalent if local time is January 11, 1990, 8pm Pacific Stan- dard Time, eight hours west of Coordinated Univer- sal Time (UTC): @{b}8:00@{ub} @{b}pm@{ub} @{b}lt@{ub} @{b}4:00@{ub} @{b}AM,@{ub} @{b}Jan.@{ub} @{b}12,@{ub} @{b}1990@{ub} default is UTC @{b}1990-01-12@{ub} @{b}04:00:00+00@{ub} ISO 8601 (UTC) @{b}1990-01-11@{ub} @{b}20:00:00-08@{ub} ISO 8601 (local time) @{b}1990/01/12@{ub} @{b}04:00:00@{ub} traditional RCS format @{b}Thu@{ub} @{b}Jan@{ub} @{b}11@{ub} @{b}20:00:00@{ub} @{b}1990@{ub} @{b}LT@{ub} output of @{b}@{i}ctime@{ui}@{ub} + @{b}LT@{ub} @{b}Thu@{ub} @{b}Jan@{ub} @{b}11@{ub} @{b}20:00:00@{ub} @{b}PST@{ub} @{b}1990@{ub} output of @{b}@{i}date@{ui}@{ub} @{b}Fri@{ub} @{b}Jan@{ub} @{b}12@{ub} @{b}04:00:00@{ub} @{b}GMT@{ub} @{b}1990@{ub} @{b}Thu,@{ub} @{b}11@{ub} @{b}Jan@{ub} @{b}1990@{ub} @{b}20:00:00@{ub} @{b}-0800@{ub} Internet RFC 822 @{b}12-January-1990,@{ub} @{b}04:00@{ub} @{b}WET@{ub} Most fields in the date and time can be defaulted. The default time zone is normally UTC, but this can be overridden by the @{b}-z@{ub} option. The other defaults are determined in the order year, month, day, hour, minute, and second (most to least significant). At least one of these fields must be provided. For omitted fields that are of higher significance than the highest provided field, the time zone's current values are assumed. For all other omitted fields, the lowest possible values are assumed. For exam- ple, without @{b}-z@{ub}, the date @{b}20,@{ub} @{b}10:30@{ub} defaults to 10:30:00 UTC of the 20th of the UTC time zone's current month and year. The date/time must be quoted if it contains spaces. @{b}-M@{ub}[@{u}rev@{uu}] Set the modification time on the new working file to be the date of the retrieved revision. Use this option with care; it can confuse @{b}@{i}make@{ui}@{ub}. @{b}-s@{u}state@{ub}@{uu} retrieves the latest revision on the selected branch whose state is set to @{u}state@{uu}. @{b}-T@{ub} Preserve the modification time on the RCS file even if the RCS file changes because a lock is added or removed. This option can suppress extensive recom- pilation caused by a @{b}@{i}make@{ui}@{ub} dependency of some other copy of the working file on the RCS file. Use this option with care; it can suppress recompi- lation even when it is needed, i.e. when the change of lock would mean a change to keyword strings in the other working file. @{b}-w@{ub}[@{u}login@{uu}] retrieves the latest revision on the selected branch which was checked in by the user with login name @{u}login@{uu}. If the argument @{u}login@{uu} is omitted, the caller's login is assumed. @{b}-j@{u}joinlist@{ub}@{uu} generates a new revision which is the join of the revisions on @{u}joinlist@{uu}. This option is largely obsoleted by @{b}@{"rcsmerge" link RCSMERGE}@{ub} but is retained for back- wards compatibility. The @{u}joinlist@{uu} is a comma-separated list of pairs of the form @{u}rev2@{b}:rev3,@{ub}@{uu} where @{u}rev2@{uu} and @{u}rev3@{uu} are (sym- bolic or numeric) revision numbers. For the ini- tial such pair, @{u}rev1@{uu} denotes the revision selected by the above options @{b}-f@{ub}, ..., @{b}-w@{ub}. For all other pairs, @{u}rev1@{uu} denotes the revision generated by the previous pair. (Thus, the output of one join becomes the input to the next.) For each pair, @{b}co@{ub} joins revisions @{u}rev1@{uu} and @{u}rev3@{uu} with respect to @{u}rev2@{uu}. This means that all changes that transform @{u}rev2@{uu} into @{u}rev1@{uu} are applied to a copy of @{u}rev3@{uu}. This is particularly useful if @{u}rev1@{uu} and @{u}rev3@{uu} are the ends of two branches that have @{u}rev2@{uu} as a common ancestor. If @{u}rev1@{uu}<@{u}rev2@{uu}<@{u}rev3@{uu} on the same branch, joining generates a new revision which is like @{u}rev3,@{uu} but with all changes that lead from @{u}rev1@{uu} to @{u}rev2@{uu} undone. If changes from @{u}rev2@{uu} to @{u}rev1@{uu} over- lap with changes from @{u}rev2@{uu} to @{u}rev3,@{uu} @{b}co@{ub} reports overlaps as described in @{b}@{"merge" link MERGE}@{ub}. For the initial pair, @{u}rev2@{uu} can be omitted. The default is the common ancestor. If any of the arguments indicate branches, the latest revisions on those branches are assumed. The options @{b}-l@{ub} and @{b}-u@{ub} lock or unlock @{u}rev1@{uu}. @{b}-V@{ub} Print RCS's version number. @{b}-V@{u}n@{ub}@{uu} Emulate RCS version @{u}n,@{uu} where @{u}n@{uu} can be @{b}3@{ub}, @{b}4@{ub}, or @{b}5@{ub}. This can be useful when interchanging RCS files with others who are running older versions of RCS. To see which version of RCS your correspondents are running, have them invoke @{b}rcs@{ub} @{b}-V@{ub}; this works with newer versions of RCS. If it doesn't work, have them invoke @{b}rlog@{ub} on an RCS file; if none of the first few lines of output contain the string @{b}branch:@{ub} it is version 3; if the dates' years have just two digits, it is version 4; otherwise, it is version 5. An RCS file generated while emulating version 3 loses its default branch. An RCS revi- sion generated while emulating version 4 or earlier has a time stamp that is off by up to 13 hours. A revision extracted while emulating version 4 or earlier contains abbreviated dates of the form @{u}yy@{b}/mm/dd@{ub}@{uu} and can also contain different white space and line prefixes in the substitution for @{b}$Log$@{ub}. @{b}-x@{u}suffixes@{ub}@{uu} Use @{u}suffixes@{uu} to characterize RCS files. See @{b}@{"ci" link CI}@{ub} for details. @{b}-z@{u}zone@{ub}@{uu} specifies the date output format in keyword substi- tution, and specifies the default time zone for @{u}date@{uu} in the @{b}-d@{u}date@{ub}@{uu} option. The @{u}zone@{uu} should be empty, a numeric UTC offset, or the special string @{b}LT@{ub} for local time. The default is an empty @{u}zone@{uu}, which uses the traditional RCS format of UTC with- out any time zone indication and with slashes sepa- rating the parts of the date; otherwise, times are output in ISO 8601 format with time zone indica- tion. For example, if local time is January 11, 1990, 8pm Pacific Standard Time, eight hours west of UTC, then the time is output as follows: @{u}option@{uu} @{u}time@{uu} @{u}output@{uu} @{b}-z@{ub} @{b}1990/01/12@{ub} @{b}04:00:00@{ub} @{u}(default)@{uu} @{b}-zLT@{ub} @{b}1990-01-11@{ub} @{b}20:00:00-08@{ub} @{b}-z+05:30@{ub} @{b}1990-01-12@{ub} @{b}09:30:00+05:30@{ub} The @{b}-z@{ub} option does not affect dates stored in RCS files, which are always UTC. @{b}KEYWORD@{ub} @{b}SUBSTITUTION@{ub} Strings of the form @{b}$@{u}keyword$@{ub}@{uu} and @{b}$@{u}keyword:...$@{ub}@{uu} embedded in the text are replaced with strings of the form @{b}$@{u}key-@{ub}@{uu} @{u}word@{b}:value$@{ub}@{uu} where @{u}keyword@{uu} and @{u}value@{uu} are pairs listed below. Keywords can be embedded in literal strings or comments to identify a revision. Initially, the user enters strings of the form @{b}$@{u}keyword$.@{ub}@{uu} On checkout, @{b}co@{ub} replaces these strings with strings of the form @{b}$@{u}keyword:value$.@{ub}@{uu} If a revision containing strings of the latter form is checked back in, the value fields will be replaced during the next checkout. Thus, the keyword values are automatically updated on checkout. This auto- matic substitution can be modified by the @{b}-k@{ub} options. Keywords and their corresponding values: @{b}$Author$@{ub} The login name of the user who checked in the revi- sion. @{b}$Date$@{ub} The date and time the revision was checked in. With @{b}-z@{u}zone@{ub}@{uu} a numeric time zone offset is appended; otherwise, the date is UTC. @{b}$Header$@{ub} A standard header containing the full pathname of the RCS file, the revision number, the date and time, the author, the state, and the locker (if locked). With @{b}-z@{u}zone@{ub}@{uu} a numeric time zone offset is appended to the date; otherwise, the date is UTC. @{b}$Id$@{ub} Same as @{b}$Header$@{ub}, except that the RCS filename is without a path. @{b}$Locker$@{ub} The login name of the user who locked the revision (empty if not locked). @{b}$Log$@{ub} The log message supplied during checkin, preceded by a header containing the RCS filename, the revi- sion number, the author, and the date and time. With @{b}-z@{u}zone@{ub}@{uu} a numeric time zone offset is appended; otherwise, the date is UTC. Existing log messages are @{u}not@{uu} replaced. Instead, the new log message is inserted after @{b}$Log:@{ub}...@{b}$@{ub}. This is useful for accu- mulating a complete change log in a source file. Each inserted line is prefixed by the string that prefixes the @{b}$Log$@{ub} line. For example, if the @{b}$Log$@{ub} line is "@{b}//@{ub} @{b}$Log:@{ub} @{b}tan.cc@{ub} @{b}$@{ub}", RCS prefixes each line of the log with "@{b}//@{ub} ". This is useful for lan- guages with comments that go to the end of the line. The convention for other languages is to use a " @{b}*@{ub} " prefix inside a multiline comment. For example, the initial log comment of a C program conventionally is of the following form: @{b}/*@{ub} @{b}*@{ub} @{b}$Log$@{ub} @{b}*/@{ub} For backwards compatibility with older versions of RCS, if the log prefix is @{b}/*@{ub} or @{b}(*@{ub} surrounded by optional white space, inserted log lines contain a space instead of @{b}/@{ub} or @{b}(@{ub}; however, this usage is obsolescent and should not be relied on. @{b}$Name$@{ub} The symbolic name used to check out the revision, if any. For example, @{b}co@{ub} @{b}-rJoe@{ub} generates @{b}$Name:@{ub} @{b}Joe@{ub} @{b}$@{ub}. Plain @{b}co@{ub} generates just @{b}$Name:@{ub} @{b}$@{ub}. @{b}$RCSfile$@{ub} The name of the RCS file without a path. @{b}$Revision$@{ub} The revision number assigned to the revision. @{b}$Source$@{ub} The full pathname of the RCS file. @{b}$State$@{ub} The state assigned to the revision with the @{b}-s@{ub} option of @{b}@{"rcs" link RCS}@{ub} or @{b}@{"ci" link CI}@{ub}. The following characters in keyword values are represented by escape sequences to keep keyword strings well-formed. @{u}char@{uu} @{u}escape@{uu} @{u}sequence@{uu} tab @{b}\\t@{ub} newline @{b}\\n@{ub} space @{b}\\040@{ub} @{b}$@{ub} @{b}\\044@{ub} @{b}\\@{ub} @{b}\\\\@{ub} @{b}FILE@{ub} @{b}MODES@{ub} The working file inherits the read and execute permissions from the RCS file. In addition, the owner write permis- sion is turned on, unless @{b}-kv@{ub} is set or the file is checked out unlocked and locking is set to strict (see @{b}@{"rcs" link RCS}@{ub}). If a file with the name of the working file exists already and has write permission, @{b}co@{ub} aborts the checkout, asking beforehand if possible. If the existing working file is not writable or @{b}-f@{ub} is given, the working file is deleted without asking. @{b}FILES@{ub} @{b}co@{ub} accesses files much as @{b}@{"ci" link CI}@{ub} does, except that it does not need to read the working file unless a revision number of @{b}$@{ub} is specified. @{b}ENVIRONMENT@{ub} @{b}RCSINIT@{ub} options prepended to the argument list, separated by spaces. See @{b}@{"ci" link CI}@{ub} for details. @{b}DIAGNOSTICS@{ub} The RCS pathname, the working pathname, and the revision number retrieved are written to the diagnostic output. The exit status is zero if and only if all operations were successful. @{b}IDENTIFICATION@{ub} Author: Walter F. Tichy. Manual Page Revision: 5.13; Release Date: 1995/06/01. Copyright (C) 1982, 1988, 1989 Walter F. Tichy. Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995 Paul Eggert. @{b}SEE@{ub} @{b}ALSO@{ub} @{"rcsintro" link RCSINTRO}, @{"ci" link CI}, @{i}ctime@{ui}, @{i}date@{ui}, @{"ident" link IDENT}, @{i}make@{ui}, @{"rcs" link RCS}, @{"rcsclean" link RCSCLEAN}, @{"rcsdiff" link RCSDIFF}, @{"rcsmerge" link RCSMERGE}, @{"rlog" link RLOG}, @{"rcsfile" link RCSFILE} Walter F. Tichy, RCS--A System for Version Control, @{u}Software--Practice@{uu} @{u}&@{uu} @{u}Experience@{uu} @{b}15@{ub}, 7 (July 1985), 637-654. @{b}LIMITS@{ub} Links to the RCS and working files are not preserved. There is no way to selectively suppress the expansion of keywords, except by writing them differently. In nroff and troff, this is done by embedding the null-character @{b}\\&@{ub} into the keyword. @ENDNODE @NODE IDENT "IDENT" @{b}NAME@{ub} ident - identify RCS keyword strings in files @{b}SYNOPSIS@{ub} @{b}ident@{ub} [ @{b}-q@{ub} ] [ @{b}-V@{ub} ] [ @{u}file@{uu} ... ] @{b}DESCRIPTION@{ub} @{b}ident@{ub} searches for all instances of the pattern @{b}$@{u}keyword:@{ub}@{uu} @{u}text@{uu} @{b}$@{ub} in the named files or, if no files are named, the standard input. These patterns are normally inserted automatically by the RCS command @{b}@{"co" link CO}@{ub}, but can also be inserted manually. The option @{b}-q@{ub} suppresses the warning given if there are no patterns in a file. The option @{b}-V@{ub} prints @{b}ident@{ub}'s version number. @{b}ident@{ub} works on text files as well as object files and dumps. For example, if the C program in @{b}f.c@{ub} contains @{b}#include@{ub} @{b}@{ub} @{b}static@{ub} @{b}char@{ub} @{b}const@{ub} @{b}rcsid[]@{ub} @{b}=@{ub} @{b}"$Id:@{ub} @{b}f.c,v@{ub} @{b}5.4@{ub} @{b}1993/11/09@{ub} @{b}17:40:15@{ub} @{b}eggert@{ub} @{b}Exp@{ub} @{b}$";@{ub} @{b}int@{ub} @{b}main()@{ub} @{b}{@{ub} @{b}return@{ub} @{b}printf("%s\\n",@{ub} @{b}rcsid)@{ub} @{b}==@{ub} @{b}EOF;@{ub} @{b}}@{ub} and @{b}f.c@{ub} is compiled into @{b}f.o@{ub}, then the command @{b}ident@{ub} @{b}f.c@{ub} @{b}f.o@{ub} will output @{b}f.c:@{ub} @{b}$Id:@{ub} @{b}f.c,v@{ub} @{b}5.4@{ub} @{b}1993/11/09@{ub} @{b}17:40:15@{ub} @{b}eggert@{ub} @{b}Exp@{ub} @{b}$@{ub} @{b}f.o:@{ub} @{b}$Id:@{ub} @{b}f.c,v@{ub} @{b}5.4@{ub} @{b}1993/11/09@{ub} @{b}17:40:15@{ub} @{b}eggert@{ub} @{b}Exp@{ub} @{b}$@{ub} If a C program defines a string like @{b}rcsid@{ub} above but does not use it, @{b}@{i}lint@{ui}@{ub} may complain, and some C compilers will optimize away the string. The most reliable solution is to have the program use the @{b}rcsid@{ub} string, as shown in the example above. @{b}ident@{ub} finds all instances of the @{b}$@{u}keyword:@{ub}@{uu} @{u}text@{uu} @{b}$@{ub} pattern, even if @{u}keyword@{uu} is not actually an RCS-supported keyword. This gives you information about nonstandard keywords like @{b}$XConsortium$@{ub}. @{b}KEYWORDS@{ub} Here is the list of keywords currently maintained by @{b}@{"co" link CO}@{ub}. All times are given in Coordinated Universal Time (UTC, sometimes called GMT) by default, but if the files were checked out with @{b}co@{ub}'s @{b}-z@{u}zone@{ub}@{uu} option, times are given with a numeric time zone indication appended. @{b}$Author$@{ub} The login name of the user who checked in the revi- sion. @{b}$Date$@{ub} The date and time the revision was checked in. @{b}$Header$@{ub} A standard header containing the full pathname of the RCS file, the revision number, the date and time, the author, the state, and the locker (if locked). @{b}$Id$@{ub} Same as @{b}$Header$@{ub}, except that the RCS filename is without a path. @{b}$Locker$@{ub} The login name of the user who locked the revision (empty if not locked). @{b}$Log$@{ub} The log message supplied during checkin. For @{b}ident@{ub}'s purposes, this is equivalent to @{b}$RCSfile$@{ub}. @{b}$Name$@{ub} The symbolic name used to check out the revision, if any. @{b}$RCSfile$@{ub} The name of the RCS file without a path. @{b}$Revision$@{ub} The revision number assigned to the revision. @{b}$Source$@{ub} The full pathname of the RCS file. @{b}$State$@{ub} The state assigned to the revision with the @{b}-s@{ub} option of @{b}@{"rcs" link RCS}@{ub} or @{b}@{"ci" link CI}@{ub}. @{b}@{"co" link CO}@{ub} represents the following characters in keyword val- ues by escape sequences to keep keyword strings well- formed. @{u}char@{uu} @{u}escape@{uu} @{u}sequence@{uu} tab @{b}\\t@{ub} newline @{b}\\n@{ub} space @{b}\\040@{ub} @{b}$@{ub} @{b}\\044@{ub} @{b}\\@{ub} @{b}\\\\@{ub} @{b}IDENTIFICATION@{ub} Author: Walter F. Tichy. Manual Page Revision: 5.4; Release Date: 1993/11/09. Copyright (C) 1982, 1988, 1989 Walter F. Tichy. Copyright (C) 1990, 1992, 1993 Paul Eggert. @{b}SEE@{ub} @{b}ALSO@{ub} @{"ci" link CI}, @{"co" link CO}, @{"rcs" link RCS}, @{"rcsdiff" link RCSDIFF}, @{"rcsintro" link RCSINTRO}, @{"rcsmerge" link RCSMERGE}, @{"rlog" link RLOG}, @{"rcsfile" link RCSFILE} Walter F. Tichy, RCS--A System for Version Control, @{u}Software--Practice@{uu} @{u}&@{uu} @{u}Experience@{uu} @{b}15@{ub}, 7 (July 1985), 637-654. @ENDNODE @NODE MERGE "MERGE" @{b}NAME@{ub} merge - three-way file merge @{b}SYNOPSIS@{ub} @{b}merge@{ub} [ @{u}options@{uu} ] @{u}file1@{uu} @{u}file2@{uu} @{u}file3@{uu} @{b}DESCRIPTION@{ub} @{b}merge@{ub} incorporates all changes that lead from @{u}file2@{uu} to @{u}file3@{uu} into @{u}file1@{uu}. The result ordinarily goes into @{u}file1@{uu}. @{b}merge@{ub} is useful for combining separate changes to an orig- inal. Suppose @{u}file2@{uu} is the original, and both @{u}file1@{uu} and @{u}file3@{uu} are modifications of @{u}file2@{uu}. Then @{b}merge@{ub} combines both changes. A conflict occurs if both @{u}file1@{uu} and @{u}file3@{uu} have changes in a common segment of lines. If a conflict is found, @{b}merge@{ub} normally outputs a warning and brackets the conflict with @{b}<<<<<<<@{ub} and @{b}>>>>>>>@{ub} lines. A typical conflict will look like this: @{b}<<<<<<<@{ub} @{u}file@{uu} @{u}A@{uu} @{u}lines@{uu} @{u}in@{uu} @{u}file@{uu} @{u}A@{uu} @{b}=======@{ub} @{u}lines@{uu} @{u}in@{uu} @{u}file@{uu} @{u}B@{uu} @{b}>>>>>>>@{ub} @{u}file@{uu} @{u}B@{uu} If there are conflicts, the user should edit the result and delete one of the alternatives. @{b}OPTIONS@{ub} @{b}-A@{ub} Output conflicts using the @{b}-A@{ub} style of @{b}@{i}diff3@{ui}@{ub}, if supported by @{b}diff3@{ub}. This merges all changes lead- ing from @{u}file2@{uu} to @{u}file3@{uu} into @{u}file1@{uu}, and generates the most verbose output. @{b}-E@{ub}, @{b}-e@{ub} These options specify conflict styles that generate less information than @{b}-A@{ub}. See @{b}@{i}diff3@{ui}@{ub} for details. The default is @{b}-E@{ub}. With @{b}-e@{ub}, @{b}merge@{ub} does not warn about conflicts. @{b}-L@{ub} @{u}label@{uu} This option may be given up to three times, and specifies labels to be used in place of the corre- sponding file names in conflict reports. That is, @{b}merge@{ub} @{b}-L@{ub} @{b}x@{ub} @{b}-L@{ub} @{b}y@{ub} @{b}-L@{ub} @{b}z@{ub} @{b}a@{ub} @{b}b@{ub} @{b}c@{ub} generates output that looks like it came from files @{b}x@{ub}, @{b}y@{ub} and @{b}z@{ub} instead of from files @{b}a@{ub}, @{b}b@{ub} and @{b}c@{ub}. @{b}-p@{ub} Send results to standard output instead of over- writing @{u}file1@{uu}. @{b}-q@{ub} Quiet; do not warn about conflicts. @{b}-V@{ub} Print 's version number. @{b}DIAGNOSTICS@{ub} Exit status is 0 for no conflicts, 1 for some conflicts, 2 for trouble. @{b}IDENTIFICATION@{ub} Author: Walter F. Tichy. Manual Page Revision: 5.7; Release Date: 1995/06/01. Copyright (C) 1982, 1988, 1989 Walter F. Tichy. Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995 Paul Eggert. @{b}SEE@{ub} @{b}ALSO@{ub} @{i}diff3@{ui}, @{i}diff@{ui}, @{"rcsmerge" link RCSMERGE}, @{"co" link CO}. @{b}BUGS@{ub} It normally does not make sense to merge binary files as if they were text, but @{b}merge@{ub} tries to do it anyway. @ENDNODE @NODE RCS "RCS" @{b}NAME@{ub} rcs - change RCS file attributes @{b}SYNOPSIS@{ub} @{b}rcs@{ub} @{u}options@{uu} @{u}file@{uu} ... @{b}DESCRIPTION@{ub} @{b}rcs@{ub} creates new RCS files or changes attributes of exist- ing ones. An RCS file contains multiple revisions of text, an access list, a change log, descriptive text, and some control attributes. For @{b}rcs@{ub} to work, the caller's login name must be on the access list, except if the access list is empty, the caller is the owner of the file or the superuser, or the @{b}-i@{ub} option is present. Pathnames matching an RCS suffix denote RCS files; all others denote working files. Names are paired as explained in @{b}@{"ci" link CI}@{ub}. Revision numbers use the syntax described in @{b}@{"ci" link CI}@{ub}. @{b}OPTIONS@{ub} @{b}-i@{ub} Create and initialize a new RCS file, but do not deposit any revision. If the RCS file has no path prefix, try to place it first into the subdirectory @{b}./RCS@{ub}, and then into the current directory. If the RCS file already exists, print an error message. @{b}-a@{u}logins@{ub}@{uu} Append the login names appearing in the comma- separated list @{u}logins@{uu} to the access list of the RCS file. @{b}-A@{u}oldfile@{ub}@{uu} Append the access list of @{u}oldfile@{uu} to the access list of the RCS file. @{b}-e@{ub}[@{u}logins@{uu}] Erase the login names appearing in the comma- separated list @{u}logins@{uu} from the access list of the RCS file. If @{u}logins@{uu} is omitted, erase the entire access list. @{b}-b@{ub}[@{u}rev@{uu}] Set the default branch to @{u}rev@{uu}. If @{u}rev@{uu} is omitted, the default branch is reset to the (dynamically) highest branch on the trunk. @{b}-c@{u}string@{ub}@{uu} Set the comment leader to @{u}string@{uu}. An initial @{b}ci@{ub}, or an @{b}rcs@{ub} @{b}-i@{ub} without @{b}-c@{ub}, guesses the comment leader from the suffix of the working filename. This option is obsolescent, since RCS normally uses the preceding @{b}$Log$@{ub} line's prefix when inserting log lines during checkout (see @{b}@{"co" link CO}@{ub}). However, older versions of RCS use the comment leader instead of the @{b}$Log$@{ub} line's prefix, so if you plan to access a file with both old and new versions of RCS, make sure its comment leader matches its @{b}$Log$@{ub} line prefix. @{b}-k@{u}subst@{ub}@{uu} Set the default keyword substitution to @{u}subst@{uu}. The effect of keyword substitution is described in @{b}@{"co" link CO}@{ub}. Giving an explicit @{b}-k@{ub} option to @{b}co@{ub}, @{b}rcsd-@{ub} @{b}iff@{ub}, and @{b}rcsmerge@{ub} overrides this default. Beware @{b}rcs@{ub} @{b}-kv@{ub}, because @{b}-kv@{ub} is incompatible with @{b}co@{ub} @{b}-l@{ub}. Use @{b}rcs@{ub} @{b}-kkv@{ub} to restore the normal default keyword substitution. @{b}-l@{ub}[@{u}rev@{uu}] Lock the revision with number @{u}rev@{uu}. If a branch is given, lock the latest revision on that branch. If @{u}rev@{uu} is omitted, lock the latest revision on the default branch. Locking prevents overlapping changes. If someone else already holds the lock, the lock is broken as with @{b}rcs@{ub} @{b}-u@{ub} (see below). @{b}-u@{ub}[@{u}rev@{uu}] Unlock the revision with number @{u}rev@{uu}. If a branch is given, unlock the latest revision on that branch. If @{u}rev@{uu} is omitted, remove the latest lock held by the caller. Normally, only the locker of a revision can unlock it. Somebody else unlocking a revision breaks the lock. This causes a mail mes- sage to be sent to the original locker. The mes- sage contains a commentary solicited from the breaker. The commentary is terminated by end-of- file or by a line containing @{b}.@{ub} by itself. @{b}-L@{ub} Set locking to @{u}strict@{uu}. Strict locking means that the owner of an RCS file is not exempt from locking for checkin. This option should be used for files that are shared. @{b}-U@{ub} Set locking to non-strict. Non-strict locking means that the owner of a file need not lock a revision for checkin. This option should @{u}not@{uu} be used for files that are shared. Whether default locking is strict is determined by your system administrator, but it is normally strict. @{b}-m@{u}rev:msg@{ub}@{uu} Replace revision @{u}rev@{uu}'s log message with @{u}msg@{uu}. @{b}-M@{ub} Do not send mail when breaking somebody else's lock. This option is not meant for casual use; it is meant for programs that warn users by other means, and invoke @{b}rcs@{ub} @{b}-u@{ub} only as a low-level lock- breaking operation. @{b}-n@{u}name@{ub}@{uu}[@{b}:@{ub}[@{u}rev@{uu}]] Associate the symbolic name @{u}name@{uu} with the branch or revision @{u}rev@{uu}. Delete the symbolic name if both @{b}:@{ub} and @{u}rev@{uu} are omitted; otherwise, print an error mes- sage if @{u}name@{uu} is already associated with another number. If @{u}rev@{uu} is symbolic, it is expanded before association. A @{u}rev@{uu} consisting of a branch number followed by a @{b}.@{ub} stands for the current latest revi- sion in the branch. A @{b}:@{ub} with an empty @{u}rev@{uu} stands for the current latest revision on the default branch, normally the trunk. For example, @{b}rcs@{ub} @{b}-n@{u}name:@{ub}@{uu} @{b}RCS/*@{ub} associates @{u}name@{uu} with the current latest revision of all the named RCS files; this contrasts with @{b}rcs@{ub} @{b}-n@{u}name:$@{ub}@{uu} @{b}RCS/*@{ub} which associates @{u}name@{uu} with the revision numbers extracted from key- word strings in the corresponding working files. @{b}-N@{u}name@{ub}@{uu}[@{b}:@{ub}[@{u}rev@{uu}]] Act like @{b}-n@{ub}, except override any previous assign- ment of @{u}name@{uu}. @{b}-o@{u}range@{ub}@{uu} deletes ("outdates") the revisions given by @{u}range@{uu}. A range consisting of a single revision number means that revision. A range consisting of a branch number means the latest revision on that branch. A range of the form @{u}rev1@{b}:rev2@{ub}@{uu} means revi- sions @{u}rev1@{uu} to @{u}rev2@{uu} on the same branch, @{b}:@{u}rev@{ub}@{uu} means from the beginning of the branch containing @{u}rev@{uu} up to and including @{u}rev@{uu}, and @{u}rev@{b}:@{ub}@{uu} means from revision @{u}rev@{uu} to the end of the branch containing @{u}rev@{uu}. None of the outdated revisions can have branches or locks. @{b}-q@{ub} Run quietly; do not print diagnostics. @{b}-I@{ub} Run interactively, even if the standard input is not a terminal. @{b}-s@{u}state@{ub}@{uu}[@{b}:@{u}rev@{ub}@{uu}] Set the state attribute of the revision @{u}rev@{uu} to @{u}state@{uu}. If @{u}rev@{uu} is a branch number, assume the lat- est revision on that branch. If @{u}rev@{uu} is omitted, assume the latest revision on the default branch. Any identifier is acceptable for @{u}state@{uu}. A useful set of states is @{b}Exp@{ub} (for experimental), @{b}Stab@{ub} (for stable), and @{b}Rel@{ub} (for released). By default, @{b}@{"ci" link CI}@{ub} sets the state of a revision to @{b}Exp@{ub}. @{b}-t@{ub}[@{u}file@{uu}] Write descriptive text from the contents of the named @{u}file@{uu} into the RCS file, deleting the existing text. The @{u}file@{uu} pathname cannot begin with @{b}-@{ub}. If @{u}file@{uu} is omitted, obtain the text from standard input, terminated by end-of-file or by a line con- taining @{b}.@{ub} by itself. Prompt for the text if inter- action is possible; see @{b}-I@{ub}. With @{b}-i@{ub}, descriptive text is obtained even if @{b}-t@{ub} is not given. @{b}-t-@{u}string@{ub}@{uu} Write descriptive text from the @{u}string@{uu} into the RCS file, deleting the existing text. @{b}-T@{ub} Preserve the modification time on the RCS file unless a revision is removed. This option can sup- press extensive recompilation caused by a @{b}@{i}make@{ui}@{ub} dependency of some copy of the working file on the RCS file. Use this option with care; it can sup- press recompilation even when it is needed, i.e. when a change to the RCS file would mean a change to keyword strings in the working file. @{b}-V@{ub} Print RCS's version number. @{b}-V@{u}n@{ub}@{uu} Emulate RCS version @{u}n@{uu}. See @{b}@{"co" link CO}@{ub} for details. @{b}-x@{u}suffixes@{ub}@{uu} Use @{u}suffixes@{uu} to characterize RCS files. See @{b}@{"ci" link CI}@{ub} for details. @{b}-z@{u}zone@{ub}@{uu} Use @{u}zone@{uu} as the default time zone. This option has no effect; it is present for compatibility with other RCS commands. At least one explicit option must be given, to ensure com- patibility with future planned extensions to the @{b}rcs@{ub} com- mand. @{b}COMPATIBILITY@{ub} The @{b}-b@{u}rev@{ub}@{uu} option generates an RCS file that cannot be parsed by RCS version 3 or earlier. The @{b}-k@{u}subst@{ub}@{uu} options (except @{b}-kkv@{ub}) generate an RCS file that cannot be parsed by RCS version 4 or earlier. Use @{b}rcs@{ub} @{b}-V@{u}n@{ub}@{uu} to make an RCS file acceptable to RCS version @{u}n@{uu} by discarding information that would confuse version @{u}n@{uu}. RCS version 5.5 and earlier does not support the @{b}-x@{ub} option, and requires a @{b},v@{ub} suffix on an RCS pathname. @{b}FILES@{ub} @{b}rcs@{ub} accesses files much as @{b}@{"ci" link CI}@{ub} does, except that it uses the effective user for all accesses, it does not write the working file or its directory, and it does not even read the working file unless a revision number of @{b}$@{ub} is speci- fied. @{b}ENVIRONMENT@{ub} @{b}RCSINIT@{ub} options prepended to the argument list, separated by spaces. See @{b}@{"ci" link CI}@{ub} for details. @{b}DIAGNOSTICS@{ub} The RCS pathname and the revisions outdated are written to the diagnostic output. The exit status is zero if and only if all operations were successful. @{b}IDENTIFICATION@{ub} Author: Walter F. Tichy. Manual Page Revision: 5.13; Release Date: 1995/06/05. Copyright (C) 1982, 1988, 1989 Walter F. Tichy. Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995 Paul Eggert. @{b}SEE@{ub} @{b}ALSO@{ub} @{"rcsintro" link RCSINTRO}, @{"co" link CO}, @{"ci" link CI}, @{"ident" link IDENT}, @{"rcsclean" link RCSCLEAN}, @{"rcsdiff" link RCSDIFF}, @{"rcsmerge" link RCSMERGE}, @{"rlog" link RLOG}, @{"rcsfile" link RCSFILE} Walter F. Tichy, RCS--A System for Version Control, @{u}Software--Practice@{uu} @{u}&@{uu} @{u}Experience@{uu} @{b}15@{ub}, 7 (July 1985), 637-654. @{b}BUGS@{ub} A catastrophe (e.g. a system crash) can cause RCS to leave behind a semaphore file that causes later invocations of RCS to claim that the RCS file is in use. To fix this, remove the semaphore file. A semaphore file's name typi- cally begins with @{b},@{ub} or ends with @{b}_@{ub}. The separator for revision ranges in the @{b}-o@{ub} option used to be @{b}-@{ub} instead of @{b}:@{ub}, but this leads to confusion when sym- bolic names contain @{b}-@{ub}. For backwards compatibility @{b}rcs@{ub} @{b}-o@{ub} still supports the old @{b}-@{ub} separator, but it warns about this obsolete use. Symbolic names need not refer to existing revisions or branches. For example, the @{b}-o@{ub} option does not remove sym- bolic names for the outdated revisions; you must use @{b}-n@{ub} to remove the names. @ENDNODE @NODE RCSCLEAN "RCSCLEAN" @{b}NAME@{ub} rcsclean - clean up working files @{b}SYNOPSIS@{ub} @{b}rcsclean@{ub} [@{u}options@{uu}] [ @{u}file@{uu} ... ] @{b}DESCRIPTION@{ub} @{b}rcsclean@{ub} removes files that are not being worked on. @{b}rcsclean@{ub} @{b}-u@{ub} also unlocks and removes files that are being worked on but have not changed. For each @{u}file@{uu} given, @{b}rcsclean@{ub} compares the working file and a revision in the corresponding RCS file. If it finds a difference, it does nothing. Otherwise, it first unlocks the revision if the @{b}-u@{ub} option is given, and then removes the working file unless the working file is writable and the revision is locked. It logs its actions by outputting the corresponding @{b}rcs@{ub} @{b}-u@{ub} and @{b}rm@{ub} @{b}-f@{ub} commands on the standard output. Files are paired as explained in @{b}@{"ci" link CI}@{ub}. If no @{u}file@{uu} is given, all working files in the current directory are cleaned. Pathnames matching an RCS suffix denote RCS files; all others denote working files. The number of the revision to which the working file is compared may be attached to any of the options @{b}-n@{ub}, @{b}-q@{ub}, @{b}-r@{ub}, or @{b}-u@{ub}. If no revision number is specified, then if the @{b}-u@{ub} option is given and the caller has one revision locked, @{b}rcsclean@{ub} uses that revision; otherwise @{b}rcsclean@{ub} uses the latest revision on the default branch, normally the root. @{b}rcsclean@{ub} is useful for @{b}clean@{ub} targets in makefiles. See also @{b}rcs@{i}diff@{ui}@{ub}, which prints out the differences, and @{b}@{"ci" link CI}@{ub}, which normally reverts to the previous revision if a file was not changed. @{b}OPTIONS@{ub} @{b}-k@{u}subst@{ub}@{uu} Use @{u}subst@{uu} style keyword substitution when retriev- ing the revision for comparison. See @{b}@{"co" link CO}@{ub} for details. @{b}-n@{ub}[@{u}rev@{uu}] Do not actually remove any files or unlock any revisions. Using this option will tell you what @{b}rcsclean@{ub} would do without actually doing it. @{b}-q@{ub}[@{u}rev@{uu}] Do not log the actions taken on standard output. @{b}-r@{ub}[@{u}rev@{uu}] This option has no effect other than specifying the revision for comparison. @{b}-T@{ub} Preserve the modification time on the RCS file even if the RCS file changes because a lock is removed. This option can suppress extensive recompilation caused by a @{b}@{i}make@{ui}@{ub} dependency of some other copy of the working file on the RCS file. Use this option with care; it can suppress recompilation even when it is needed, i.e. when the lock removal would mean a change to keyword strings in the other working file. @{b}-u@{ub}[@{u}rev@{uu}] Unlock the revision if it is locked and no differ- ence is found. @{b}-V@{ub} Print RCS's version number. @{b}-V@{u}n@{ub}@{uu} Emulate RCS version @{u}n@{uu}. See @{b}@{"co" link CO}@{ub} for details. @{b}-x@{u}suffixes@{ub}@{uu} Use @{u}suffixes@{uu} to characterize RCS files. See @{b}@{"ci" link CI}@{ub} for details. @{b}-z@{u}zone@{ub}@{uu} Use @{u}zone@{uu} as the time zone for keyword substitution; see @{b}@{"co" link CO}@{ub} for details. @{b}EXAMPLES@{ub} @{b}rcsclean@{ub} @{b}*.c@{ub} @{b}*.h@{ub} removes all working files ending in @{b}.c@{ub} or @{b}.h@{ub} that were not changed since their checkout. @{b}rcsclean@{ub} removes all working files in the current directory that were not changed since their checkout. @{b}FILES@{ub} @{b}rcsclean@{ub} accesses files much as @{b}@{"ci" link CI}@{ub} does. @{b}ENVIRONMENT@{ub} @{b}RCSINIT@{ub} options prepended to the argument list, separated by spaces. A backslash escapes spaces within an option. The @{b}RCSINIT@{ub} options are prepended to the argument lists of most RCS commands. Useful @{b}RCSINIT@{ub} options include @{b}-q@{ub}, @{b}-V@{ub}, @{b}-x@{ub}, and @{b}-z@{ub}. @{b}DIAGNOSTICS@{ub} The exit status is zero if and only if all operations were successful. Missing working files and RCS files are silently ignored. @{b}IDENTIFICATION@{ub} Author: Walter F. Tichy. Manual Page Revision: 1.12; Release Date: 1993/11/03. Copyright (C) 1982, 1988, 1989 Walter F. Tichy. Copyright (C) 1990, 1991, 1992, 1993 Paul Eggert. @{b}SEE@{ub} @{b}ALSO@{ub} @{"ci" link CI}, @{"co" link CO}, @{"ident" link IDENT}, @{"rcs" link RCS}, @{"rcsdiff" link RCSDIFF}, @{"rcsintro" link RCSINTRO}, @{"rcsmerge" link RCSMERGE}, @{"rlog" link RLOG}, @{"rcsfile" link RCSFILE} Walter F. Tichy, RCS--A System for Version Control, @{u}Software--Practice@{uu} @{u}&@{uu} @{u}Experience@{uu} @{b}15@{ub}, 7 (July 1985), 637-654. @{b}BUGS@{ub} At least one @{u}file@{uu} must be given in older Unix versions that do not provide the needed directory scanning opera- tions. @ENDNODE @NODE RCSDIFF "RCSDIFF" @{b}NAME@{ub} rcsdiff - compare RCS revisions @{b}SYNOPSIS@{ub} @{b}rcsdiff@{ub} [ @{b}-k@{u}subst@{ub}@{uu} ] [ @{b}-q@{ub} ] [ @{b}-r@{u}rev1@{ub}@{uu} [ @{b}-r@{u}rev2@{ub}@{uu} ] ] [ @{b}-T@{ub} ] [ @{b}-V@{ub}[@{u}n@{uu}] ] [ @{b}-x@{u}suffixes@{ub}@{uu} ] [ @{b}-z@{u}zone@{ub}@{uu} ] [ @{u}diff@{uu} @{u}options@{uu} ] @{u}file@{uu} @{u}...@{uu} @{b}DESCRIPTION@{ub} @{b}rcsdiff@{ub} runs @{b}@{i}diff@{ui}@{ub} to compare two revisions of each RCS file given. Pathnames matching an RCS suffix denote RCS files; all others denote working files. Names are paired as explained in @{b}@{"ci" link CI}@{ub}. The option @{b}-q@{ub} suppresses diagnostic output. Zero, one, or two revisions may be specified with @{b}-r@{ub}. The option @{b}-k@{u}subst@{ub}@{uu} affects keyword substitution when extracting revi- sions, as described in @{b}@{"co" link CO}@{ub}; for example, @{b}-kk@{ub} @{b}-r1.1@{ub} @{b}-r1.2@{ub} ignores differences in keyword values when comparing revi- sions @{b}1.1@{ub} and @{b}1.2@{ub}. To avoid excess output from locker name substitution, @{b}-kkvl@{ub} is assumed if (1) at most one revision option is given, (2) no @{b}-k@{ub} option is given, (3) @{b}-kkv@{ub} is the default keyword substitution, and (4) the working file's mode would be produced by @{b}co@{ub} @{b}-l@{ub}. See @{b}@{"co" link CO}@{ub} for details about @{b}-T@{ub}, @{b}-V@{ub}, @{b}-x@{ub} and @{b}-z@{ub}. Otherwise, all options of @{b}@{i}diff@{ui}@{ub} that apply to regular files are accepted, with the same meaning as for @{b}diff@{ub}. If both @{u}rev1@{uu} and @{u}rev2@{uu} are omitted, @{b}rcsdiff@{ub} compares the latest revision on the default branch (by default the trunk) with the contents of the corresponding working file. This is useful for determining what you changed since the last checkin. If @{u}rev1@{uu} is given, but @{u}rev2@{uu} is omitted, @{b}rcsdiff@{ub} compares revision @{u}rev1@{uu} of the RCS file with the contents of the corresponding working file. If both @{u}rev1@{uu} and @{u}rev2@{uu} are given, @{b}rcsdiff@{ub} compares revi- sions @{u}rev1@{uu} and @{u}rev2@{uu} of the RCS file. Both @{u}rev1@{uu} and @{u}rev2@{uu} may be given numerically or symboli- cally. @{b}EXAMPLE@{ub} The command @{b}rcsdiff@{ub} @{b}f.c@{ub} compares the latest revision on the default branch of the RCS file to the contents of the working file @{b}f.c@{ub}. @{b}ENVIRONMENT@{ub} @{b}RCSINIT@{ub} options prepended to the argument list, separated by spaces. See @{b}@{"ci" link CI}@{ub} for details. @{b}DIAGNOSTICS@{ub} Exit status is 0 for no differences during any comparison, 1 for some differences, 2 for trouble. @{b}IDENTIFICATION@{ub} Author: Walter F. Tichy. Manual Page Revision: 5.5; Release Date: 1993/11/03. Copyright (C) 1982, 1988, 1989 Walter F. Tichy. Copyright (C) 1990, 1991, 1992, 1993 Paul Eggert. @{b}SEE@{ub} @{b}ALSO@{ub} @{"ci" link CI}, @{"co" link CO}, @{i}diff@{ui}, @{"ident" link IDENT}, @{"rcs" link RCS}, @{"rcsintro" link RCSINTRO}, @{"rcsmerge" link RCSMERGE}, @{"rlog" link RLOG} Walter F. Tichy, RCS--A System for Version Control, @{u}Software--Practice@{uu} @{u}&@{uu} @{u}Experience@{uu} @{b}15@{ub}, 7 (July 1985), 637-654. @ENDNODE @NODE RCSFREEZE "RCSFREEZE" @{b}NAME@{ub} rcsfreeze - freeze a configuration of sources checked in under RCS @{b}SYNOPSIS@{ub} @{b}rcsfreeze@{ub} [@{u}name@{uu}] @{b}DESCRIPTION@{ub} @{b}rcsfreeze@{ub} assigns a symbolic revision number to a set of RCS files that form a valid configuration. The idea is to run @{b}rcsfreeze@{ub} each time a new version is checked in. A unique symbolic name (@{b}C_@{u}number,@{ub}@{uu} where @{u}num-@{uu} @{u}ber@{uu} is increased each time @{b}rcsfreeze@{ub} is run) is then assigned to the most recent revision of each RCS file of the main trunk. An optional @{u}name@{uu} argument to @{b}rcsfreeze@{ub} gives a symbolic name to the configuration. The unique identifier is still generated and is listed in the log file but it will not appear as part of the symbolic revision name in the actual RCS files. A log message is requested from the user for future refer- ence. The shell script works only on all RCS files at one time. All changed files must be checked in already. Run @{u}@{"rcsclean" link RCSCLEAN}@{uu} first and see whether any sources remain in the current directory. @{b}FILES@{ub} @{b}RCS/.rcsfreeze.ver@{ub} version number @{b}RCS/.rcsfreeze.log@{ub} log messages, most recent first @{b}AUTHOR@{ub} Stephan v. Bechtolsheim @{b}SEE@{ub} @{b}ALSO@{ub} @{"co" link CO}, @{"rcs" link RCS}, @{"rcsclean" link RCSCLEAN}, @{"rlog" link RLOG} @{b}BUGS@{ub} @{b}rcsfreeze@{ub} does not check whether any sources are checked out and modified. Although both source file names and RCS file names are accepted, they are not paired as usual with RCS commands. Error checking is rudimentary. @{b}rcsfreeze@{ub} is just an optional example shell script, and should not be taken too seriously. See CVS for a more complete solution. @ENDNODE @NODE RCSMERGE "RCSMERGE" @{b}NAME@{ub} rcsmerge - merge RCS revisions @{b}SYNOPSIS@{ub} @{b}rcsmerge@{ub} [@{u}options@{uu}] @{u}file@{uu} @{b}DESCRIPTION@{ub} @{b}rcsmerge@{ub} incorporates the changes between two revisions of an RCS file into the corresponding working file. Pathnames matching an RCS suffix denote RCS files; all others denote working files. Names are paired as explained in @{b}@{"ci" link CI}@{ub}. At least one revision must be specified with one of the options described below, usually @{b}-r@{ub}. At most two revi- sions may be specified. If only one revision is speci- fied, the latest revision on the default branch (normally the highest branch on the trunk) is assumed for the second revision. Revisions may be specified numerically or sym- bolically. @{b}rcsmerge@{ub} prints a warning if there are overlaps, and delimits the overlapping regions as explained in @{b}@{"merge" link MERGE}@{ub}. The command is useful for incorporating changes into a checked-out revision. @{b}OPTIONS@{ub} @{b}-A@{ub} Output conflicts using the @{b}-A@{ub} style of @{b}@{i}diff3@{ui}@{ub}, if supported by @{b}diff3@{ub}. This merges all changes lead- ing from @{u}file2@{uu} to @{u}file3@{uu} into @{u}file1@{uu}, and generates the most verbose output. @{b}-E@{ub}, @{b}-e@{ub} These options specify conflict styles that generate less information than @{b}-A@{ub}. See @{b}@{i}diff3@{ui}@{ub} for details. The default is @{b}-E@{ub}. With @{b}-e@{ub}, @{b}rcsmerge@{ub} does not warn about conflicts. @{b}-k@{u}subst@{ub}@{uu} Use @{u}subst@{uu} style keyword substitution. See @{b}@{"co" link CO}@{ub} for details. For example, @{b}-kk@{ub} @{b}-r1.1@{ub} @{b}-r1.2@{ub} ignores differences in keyword values when merging the changes from @{b}1.1@{ub} to @{b}1.2@{ub}. It normally does not make sense to merge binary files as if they were text, so @{b}rcsmerge@{ub} refuses to merge files if @{b}-kb@{ub} expansion is used. @{b}-p@{ub}[@{u}rev@{uu}] Send the result to standard output instead of over- writing the working file. @{b}-q@{ub}[@{u}rev@{uu}] Run quietly; do not print diagnostics. @{b}-r@{ub}[@{u}rev@{uu}] Merge with respect to revision @{u}rev@{uu}. Here an empty @{u}rev@{uu} stands for the latest revision on the default branch, normally the head. @{b}-T@{ub} This option has no effect; it is present for com- patibility with other RCS commands. @{b}-V@{ub} Print RCS's version number. @{b}-V@{u}n@{ub}@{uu} Emulate RCS version @{u}n@{uu}. See @{b}@{"co" link CO}@{ub} for details. @{b}-x@{u}suffixes@{ub}@{uu} Use @{u}suffixes@{uu} to characterize RCS files. See @{b}@{"ci" link CI}@{ub} for details. @{b}-z@{u}zone@{ub}@{uu} Use @{u}zone@{uu} as the time zone for keyword substitution. See @{b}@{"co" link CO}@{ub} for details. @{b}EXAMPLES@{ub} Suppose you have released revision 2.8 of @{b}f.c@{ub}. Assume furthermore that after you complete an unreleased revision 3.4, you receive updates to release 2.8 from someone else. To combine the updates to 2.8 and your changes between 2.8 and 3.4, put the updates to 2.8 into file f.c and execute @{b}rcsmerge@{ub} @{b}-p@{ub} @{b}-r2.8@{ub} @{b}-r3.4@{ub} @{b}f.c@{ub} @{b}>f.merged.c@{ub} Then examine @{b}f.merged.c@{ub}. Alternatively, if you want to save the updates to 2.8 in the RCS file, check them in as revision 2.8.1.1 and execute @{b}co@{ub} @{b}-j@{ub}: @{b}ci@{ub} @{b}-r2.8.1.1@{ub} @{b}f.c@{ub} @{b}co@{ub} @{b}-r3.4@{ub} @{b}-j2.8:2.8.1.1@{ub} @{b}f.c@{ub} As another example, the following command undoes the changes between revision 2.4 and 2.8 in your currently checked out revision in @{b}f.c@{ub}. @{b}rcsmerge@{ub} @{b}-r2.8@{ub} @{b}-r2.4@{ub} @{b}f.c@{ub} Note the order of the arguments, and that @{b}f.c@{ub} will be overwritten. @{b}ENVIRONMENT@{ub} @{b}RCSINIT@{ub} options prepended to the argument list, separated by spaces. See @{b}@{"ci" link CI}@{ub} for details. @{b}DIAGNOSTICS@{ub} Exit status is 0 for no overlaps, 1 for some overlaps, 2 for trouble. @{b}IDENTIFICATION@{ub} Author: Walter F. Tichy. Manual Page Revision: 5.6; Release Date: 1995/06/01. Copyright (C) 1982, 1988, 1989 Walter F. Tichy. Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995 Paul Eggert. @{b}SEE@{ub} @{b}ALSO@{ub} @{"ci" link CI}, @{"co" link CO}, @{"ident" link IDENT}, @{"merge" link MERGE}, @{"rcs" link RCS}, @{"rcsdiff" link RCSDIFF}, @{"rcsintro" link RCSINTRO}, @{"rlog" link RLOG}, @{"rcsfile" link RCSFILE} Walter F. Tichy, RCS--A System for Version Control, @{u}Software--Practice@{uu} @{u}&@{uu} @{u}Experience@{uu} @{b}15@{ub}, 7 (July 1985), 637-654. @ENDNODE @NODE RLOG "RLOG" @{b}NAME@{ub} rlog - print log messages and other information about RCS files @{b}SYNOPSIS@{ub} @{b}rlog@{ub} [ @{u}options@{uu} ] @{u}file@{uu} ... @{b}DESCRIPTION@{ub} @{b}rlog@{ub} prints information about RCS files. Pathnames matching an RCS suffix denote RCS files; all others denote working files. Names are paired as explained in @{b}@{"ci" link CI}@{ub}. @{b}rlog@{ub} prints the following information for each RCS file: RCS pathname, working pathname, head (i.e., the number of the latest revision on the trunk), default branch, access list, locks, symbolic names, suffix, total number of revi- sions, number of revisions selected for printing, and descriptive text. This is followed by entries for the selected revisions in reverse chronological order for each branch. For each revision, @{b}rlog@{ub} prints revision number, author, date/time, state, number of lines added/deleted (with respect to the previous revision), locker of the revision (if any), and log message. All times are dis- played in Coordinated Universal Time (UTC) by default; this can be overridden with @{b}-z@{ub}. Without options, @{b}rlog@{ub} prints complete information. The options below restrict this output. @{b}-L@{ub} Ignore RCS files that have no locks set. This is con- venient in combination with @{b}-h@{ub}, @{b}-l@{ub}, and @{b}-R@{ub}. @{b}-R@{ub} Print only the name of the RCS file. This is conve- nient for translating a working pathname into an RCS pathname. @{b}-h@{ub} Print only the RCS pathname, working pathname, head, default branch, access list, locks, symbolic names, and suffix. @{b}-t@{ub} Print the same as @{b}-h@{ub}, plus the descriptive text. @{b}-N@{ub} Do not print the symbolic names. @{b}-b@{ub} Print information about the revisions on the default branch, normally the highest branch on the trunk. @{b}-d@{u}dates@{ub}@{uu} Print information about revisions with a checkin date/time in the ranges given by the semicolon- separated list of @{u}dates@{uu}. A range of the form @{u}d1@{b}d1@{ub}@{uu} selects the revisions that were deposited between @{u}d1@{uu} and @{u}d2@{uu} exclusive. A range of the form @{b}<@{u}d@{ub}@{uu} or @{u}d@{b}>@{ub}@{uu} selects all revisions earlier than @{u}d@{uu}. A range of the form @{u}d@{b}<@{ub}@{uu} or @{b}>@{u}d@{ub}@{uu} selects all revisions dated later than @{u}d@{uu}. If @{b}<@{ub} or @{b}>@{ub} is followed by @{b}=@{ub} then the ranges are inclusive, not exclusive. A range of the form @{u}d@{uu} selects the single, latest revision dated @{u}d@{uu} or ear- lier. The date/time strings @{u}d@{uu}, @{u}d1@{uu}, and @{u}d2@{uu} are in the free format explained in @{b}@{"co" link CO}@{ub}. Quoting is normally necessary, especially for @{b}<@{ub} and @{b}>@{ub}. Note that the sep- arator is a semicolon. @{b}-l@{ub}[@{u}lockers@{uu}] Print information about locked revisions only. In addition, if the comma-separated list @{u}lockers@{uu} of login names is given, ignore all locks other than those held by the @{u}lockers@{uu}. For example, @{b}rlog@{ub} @{b}-L@{ub} @{b}-R@{ub} @{b}-lwft@{ub} @{b}RCS/*@{ub} prints the name of RCS files locked by the user @{b}wft@{ub}. @{b}-r@{ub}[@{u}revisions@{uu}] prints information about revisions given in the comma- separated list @{u}revisions@{uu} of revisions and ranges. A range @{u}rev1@{b}:rev2@{ub}@{uu} means revisions @{u}rev1@{uu} to @{u}rev2@{uu} on the same branch, @{b}:@{u}rev@{ub}@{uu} means revisions from the beginning of the branch up to and including @{u}rev@{uu}, and @{u}rev@{b}:@{ub}@{uu} means revisions starting with @{u}rev@{uu} to the end of the branch containing @{u}rev@{uu}. An argument that is a branch means all revisions on that branch. A range of branches means all revisions on the branches in that range. A branch followed by a @{b}.@{ub} means the latest revision in that branch. A bare @{b}-r@{ub} with no @{u}revisions@{uu} means the latest revision on the default branch, normally the trunk. @{b}-s@{u}states@{ub}@{uu} prints information about revisions whose state attributes match one of the states given in the comma- separated list @{u}states@{uu}. @{b}-w@{ub}[@{u}logins@{uu}] prints information about revisions checked in by users with login names appearing in the comma-separated list @{u}logins@{uu}. If @{u}logins@{uu} is omitted, the user's login is assumed. @{b}-T@{ub} This option has no effect; it is present for compati- bility with other RCS commands. @{b}-V@{ub} Print RCS's version number. @{b}-V@{u}n@{ub}@{uu} Emulate RCS version @{u}n@{uu} when generating logs. See @{b}@{"co" link CO}@{ub} for more. @{b}-x@{u}suffixes@{ub}@{uu} Use @{u}suffixes@{uu} to characterize RCS files. See @{b}@{"ci" link CI}@{ub} for details. @{b}rlog@{ub} prints the intersection of the revisions selected with the options @{b}-d@{ub}, @{b}-l@{ub}, @{b}-s@{ub}, and @{b}-w@{ub}, intersected with the union of the revisions selected by @{b}-b@{ub} and @{b}-r@{ub}. @{b}-z@{u}zone@{ub}@{uu} specifies the date output format, and specifies the default time zone for @{u}date@{uu} in the @{b}-d@{u}dates@{ub}@{uu} option. The @{u}zone@{uu} should be empty, a numeric UTC offset, or the special string @{b}LT@{ub} for local time. The default is an empty @{u}zone@{uu}, which uses the traditional RCS format of UTC without any time zone indication and with slashes separating the parts of the date; oth- erwise, times are output in ISO 8601 format with time zone indication. For example, if local time is January 11, 1990, 8pm Pacific Standard Time, eight hours west of UTC, then the time is output as follows: @{u}option@{uu} @{u}time@{uu} @{u}output@{uu} @{b}-z@{ub} @{b}1990/01/12@{ub} @{b}04:00:00@{ub} @{u}(default)@{uu} @{b}-zLT@{ub} @{b}1990-01-11@{ub} @{b}20:00:00-08@{ub} @{b}-z+05:30@{ub} @{b}1990-01-12@{ub} @{b}09:30:00+05:30@{ub} @{b}EXAMPLES@{ub} @{b}rlog@{ub} @{b}-L@{ub} @{b}-R@{ub} @{b}RCS/*@{ub} @{b}rlog@{ub} @{b}-L@{ub} @{b}-h@{ub} @{b}RCS/*@{ub} @{b}rlog@{ub} @{b}-L@{ub} @{b}-l@{ub} @{b}RCS/*@{ub} @{b}rlog@{ub} @{b}RCS/*@{ub} The first command prints the names of all RCS files in the subdirectory @{b}RCS@{ub} that have locks. The second command prints the headers of those files, and the third prints the headers plus the log messages of the locked revisions. The last command prints complete information. @{b}ENVIRONMENT@{ub} @{b}RCSINIT@{ub} options prepended to the argument list, separated by spaces. See @{b}@{"ci" link CI}@{ub} for details. @{b}DIAGNOSTICS@{ub} The exit status is zero if and only if all operations were successful. @{b}IDENTIFICATION@{ub} Author: Walter F. Tichy. Manual Page Revision: 5.9; Release Date: 1995/06/16. Copyright (C) 1982, 1988, 1989 Walter F. Tichy. Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995 Paul Eggert. @{b}SEE@{ub} @{b}ALSO@{ub} @{"ci" link CI}, @{"co" link CO}, @{"ident" link IDENT}, @{"rcs" link RCS}, @{"rcsdiff" link RCSDIFF}, @{"rcsintro" link RCSINTRO}, @{"rcsmerge" link RCSMERGE}, @{"rcsfile" link RCSFILE} Walter F. Tichy, RCS--A System for Version Control, @{u}Software--Practice@{uu} @{u}&@{uu} @{u}Experience@{uu} @{b}15@{ub}, 7 (July 1985), 637-654. @{b}BUGS@{ub} The separator for revision ranges in the @{b}-r@{ub} option used to be @{b}-@{ub} instead of @{b}:@{ub}, but this leads to confusion when sym- bolic names contain @{b}-@{ub}. For backwards compatibility @{b}rlog@{ub} @{b}-r@{ub} still supports the old @{b}-@{ub} separator, but it warns about this obsolete use. @ENDNODE @NODE RCSFILE "RCSFILE" @{b}NAME@{ub} rcsfile - format of RCS file @{b}DESCRIPTION@{ub} An RCS file's contents are described by the grammar below. The text is free format: space, backspace, tab, newline, vertical tab, form feed, and carriage return (collec- tively, @{u}white@{uu} @{u}space@{uu}) have no significance except in strings. However, white space cannot appear within an id, num, or sym, and an RCS file must end with a newline. Strings are enclosed by @{b}@@{ub}. If a string contains a @{b}@@{ub}, it must be doubled; otherwise, strings can contain arbitrary binary data. The meta syntax uses the following conventions: `|' (bar) separates alternatives; `{' and `}' enclose optional phrases; `{' and `}*' enclose phrases that can be repeated zero or more times; `{' and '}+' enclose phrases that must appear at least once and can be repeated; Terminal symbols are in @{b}boldface@{ub}; nonterminal symbols are in @{u}italics@{uu}. @{u}rcstext@{uu} ::= @{u}admin@{uu} {@{u}delta@{uu}}* @{u}desc@{uu} {@{u}deltatext@{uu}}* @{u}admin@{uu} ::= @{b}head@{ub} {@{u}num@{uu}}@{b};@{ub} { @{b}branch@{ub} {@{u}num@{uu}}@{b};@{ub} } @{b}access@{ub} {@{u}id@{uu}}*@{b};@{ub} @{b}symbols@{ub} {@{u}sym@{uu} @{b}:@{ub} @{u}num@{uu}}*@{b};@{ub} @{b}locks@{ub} {@{u}id@{uu} @{b}:@{ub} @{u}num@{uu}}*@{b};@{ub} {@{b}strict@{ub} @{b};@{ub}} { @{b}comment@{ub} {@{u}string@{uu}}@{b};@{ub} } { @{b}expand@{ub} {@{u}string@{uu}}@{b};@{ub} } { @{u}newphrase@{uu} }* @{u}delta@{uu} ::= @{u}num@{uu} @{b}date@{ub} @{u}num@{b};@{ub}@{uu} @{b}author@{ub} @{u}id@{b};@{ub}@{uu} @{b}state@{ub} {@{u}id@{uu}}@{b};@{ub} @{b}branches@{ub} {@{u}num@{uu}}*@{b};@{ub} @{b}next@{ub} {@{u}num@{uu}}@{b};@{ub} { @{u}newphrase@{uu} }* @{u}desc@{uu} ::= @{b}desc@{ub} @{u}string@{uu} @{u}deltatext@{uu} ::= @{u}num@{uu} @{b}log@{ub} @{u}string@{uu} { @{u}newphrase@{uu} }* @{b}text@{ub} @{u}string@{uu} @{u}num@{uu} ::= {@{u}digit@{uu} | @{b}.@{ub}}+ @{u}digit@{uu} ::= @{b}0@{ub} | @{b}1@{ub} | @{b}2@{ub} | @{b}3@{ub} | @{b}4@{ub} | @{b}5@{ub} | @{b}6@{ub} | @{b}7@{ub} | @{b}8@{ub} | @{b}9@{ub} @{u}id@{uu} ::= {@{u}num@{uu}} @{u}idchar@{uu} {@{u}idchar@{uu} | @{u}num@{uu}}* @{u}sym@{uu} ::= {@{u}digit@{uu}}* @{u}idchar@{uu} {@{u}idchar@{uu} | @{u}digit@{uu}}* @{u}idchar@{uu} ::= any visible graphic character except @{u}special@{uu} @{u}special@{uu} ::= @{b}$@{ub} | @{b},@{ub} | @{b}.@{ub} | @{b}:@{ub} | @{b};@{ub} | @{b}@@{ub} @{u}string@{uu} ::= @{b}@@{ub}{any character, with @{b}@@{ub} doubled}*@{b}@@{ub} @{u}newphrase@{uu} ::= @{u}id@{uu} @{u}word@{uu}* @{b};@{ub} @{u}word@{uu} ::= @{u}id@{uu} | @{u}num@{uu} | @{u}string@{uu} | @{b}:@{ub} Identifiers are case sensitive. Keywords are in lower case only. The sets of keywords and identifiers can over- lap. In most environments RCS uses the ISO 8859/1 encod- ing: visible graphic characters are codes 041-176 and 240-377, and white space characters are codes 010-015 and 040. Dates, which appear after the @{b}date@{ub} keyword, are of the form @{u}Y@{b}.mm.dd.hh.mm.ss@{ub}@{uu}, where @{u}Y@{uu} is the year, @{u}mm@{uu} the month (01-12), @{u}dd@{uu} the day (01-31), @{u}hh@{uu} the hour (00-23), @{u}mm@{uu} the minute (00-59), and @{u}ss@{uu} the second (00-60). @{u}Y@{uu} contains just the last two digits of the year for years from 1900 through 1999, and all the digits of years thereafter. Dates use the Gregorian calendar; times use UTC. The @{u}newphrase@{uu} productions in the grammar are reserved for future extensions to the format of RCS files. No @{u}new-@{uu} @{u}phrase@{uu} will begin with any keyword already in use. The @{u}delta@{uu} nodes form a tree. All nodes whose numbers con- sist of a single pair (e.g., 2.3, 2.1, 1.3, etc.) are on the trunk, and are linked through the @{b}next@{ub} field in order of decreasing numbers. The @{b}head@{ub} field in the @{u}admin@{uu} node points to the head of that sequence (i.e., contains the highest pair). The @{b}branch@{ub} node in the admin node indi- cates the default branch (or revision) for most RCS opera- tions. If empty, the default branch is the highest branch on the trunk. All @{u}delta@{uu} nodes whose numbers consist of 2@{u}n@{uu} fields (@{u}n@{uu}>=2) (e.g., 3.1.1.1, 2.1.2.2, etc.) are linked as follows. All nodes whose first 2@{u}n@{uu}-1 number fields are identical are linked through the @{b}next@{ub} field in order of increasing num- bers. For each such sequence, the @{u}delta@{uu} node whose number is identical to the first 2@{u}n@{uu}-2 number fields of the deltas on that sequence is called the branchpoint. The @{b}branches@{ub} field of a node contains a list of the numbers of the first nodes of all sequences for which it is a branch- point. This list is ordered in increasing numbers. The following diagram shows an example of an RCS file's organization. Head | | v / \\ --------- / \\ / \\ / \\ | | / \\ / \\ / \\ / \\ | 2.1 | / \\ / \\ / \\ / \\ | | / \\ / \\ /1.2.1.3\\ /1.3.1.1\\ | | /1.2.2.2\\ /1.2.2.1.1.1\\ --------- --------- --------- --------- ------------- ^ ^ | ^ ^ | | | | | | | v | | / \\ | --------- / \\ | / \\ | \\ 1.3 / / \\ | / \\ ---------\\ / / \\----------- /1.2.1.1\\ \\ / /1.2.2.1\\ --------- \\ / --------- ^ | ^ | | | | v | | --------- | | \\ 1.2 / | ----------------------\\ /--------- \\ / \\ / | | v --------- \\ 1.1 / \\ / \\ / \\ / @{b}IDENTIFICATION@{ub} Author: Walter F. Tichy, Purdue University, West Lafayette, IN, 47907. Manual Page Revision: 5.6; Release Date: 1995/06/05. Copyright (C) 1982, 1988, 1989 Walter F. Tichy. Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995 Paul Eggert. @{b}SEE@{ub} @{b}ALSO@{ub} @{"rcsintro" link RCSINTRO}, @{"ci" link CI}, @{"co" link CO}, @{ui}@{"ident" link IDENT}, @{"rcs" link RCS}, @{"rcsclean" link RCSCLEAN}, @{"rcsdiff" link RCSDIFF}, @{"rcsmerge" link RCSMERGE}, @{"rlog" link RLOG} Walter F. Tichy, RCS--A System for Version Control, @{u}Software--Practice@{uu} @{u}&@{uu} @{u}Experience@{uu} @{b}15@{ub}, 7 (July 1985), 637-654. @ENDNODE