This is Info file cvs.info, produced by Makeinfo-1.55 from the input file ./cvs.texinfo. Copyright (C) 1992, 1993 Signum Support AB Copyright (C) 1993, 1994 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the section entitled "GNU General Public License" is included exactly as in the original, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that the section entitled "GNU General Public License" and this permission notice may be included in translations approved by the Free Software Foundation instead of in the original English.  File: cvs.info, Node: add options, Next: add examples, Up: add add options ----------- There are only two options you can give to `add': `-k KFLAG' This option specifies the default way that this file will be checked out. See rcs(1) and co(1). The KFLAG argument (*note Substitution modes::.) is stored in the RCS file and can be changed with `admin -k' (*note admin options::.). Specifying `-ko' is useful for checking in binaries that should not have the RCS id strings expanded. *Warning:* this option is reported to be broken in version 1.3 and 1.3-s2 of CVS. Use `admin -k' after the commit instead. *Note admin examples::. `-m DESCRIPTION' Using this option, you can give a description for the file. This description appears in the history log (if it is enabled, *note history file::.). It will also be saved in the RCS history file inside the repository when the file is committed. The `log' command displays this description. The description can be changed using `admin -t'. *Note admin::. If you omit the `-m DESCRIPTION' flag, an empty string will be used. You will not be prompted for a description.  File: cvs.info, Node: add examples, Prev: add options, Up: add add examples ------------ To add the file `backend.c' to the repository, with a description, the following can be used. $ cvs add -m "Optimizer and code generation passes." backend.c $ cvs commit -m "Early version. Not yet compilable." backend.c  File: cvs.info, Node: admin, Next: checkout, Prev: add, Up: Invoking CVS admin--Administration front end for rcs ======================================= * Requires: repository, working directory. * Changes: repository. * Synonym: rcs This is the CVS interface to assorted administrative RCS facilities, documented in rcs(1). `admin' simply passes all its options and arguments to the `rcs' command; it does no filtering or other processing. This command *does* work recursively, however, so extreme care should be used. * Menu: * admin options:: admin options * admin examples:: admin examples  File: cvs.info, Node: admin options, Next: admin examples, Up: admin admin options ------------- Not all valid `rcs' options are useful together with CVS. Some even makes it impossible to use CVS until you undo the effect! This description of the available options is based on the `rcs(1)' man page, but modified to suit readers that are more interrested in CVS than RCS. `-AOLDFILE' Might not work together with CVS. Append the access list of OLDFILE to the access list of the RCS file. `-aLOGINS' Might not work together with CVS. Append the login names appearing in the comma-separated list LOGINS to the access list of the RCS file. `-b[REV]' Breaks CVS. When used with bare RCS, this option sets the default branch to REV. If REV is omitted, the default branch is reset to the (dynamically) highest branch on the trunk. Use sticky tags instead, as in `cvs co -r'. *Note Sticky tags::. `-cSTRING' Useful with CVS. Sets the comment leader to STRING. The comment leader is printed before every log message line generated by the keyword `$Log: cvs.info-3,v $ keyword `Revision 1.1 1995/12/19 09:21:39 deraadt keyword `Initial revision keyword `' (*note Keyword substitution::.). This is useful for programming languages without multi-line comments. RCS initially guesses the value of the comment leader from the file name extension when the file is first committed. `-e[LOGINS]' Might not work together with CVS. Erase the login names appearing in the comma-separated list LOGINS from the access list of the RCS file. If LOGINS is omitted, erase the entire access list. `-I' Run interactively, even if the standard input is not a terminal. `-i' Useless with CVS. When using bare RCS, this is used to create and initialize a new RCS file, without depositing a revision. `-kSUBST' Useful with CVS. Set the default keyword substitution to SUBST. *Note Keyword substitution::. Giving an explicit `-k' option to `cvs update' or `cvs checkout' overrides this default. `cvs export' always uses `-kv', regardless of which keyword substitution is set with `cvs admin'. `-l[REV]' Probably useless with CVS. With bare RCS, this option can be used to lock the revision with number REV. If a branch is given, lock the latest revision on that branch. If REV is omitted, lock the latest revision on the default branch. `-L' Probably useless with CVS. Used with bare RCS to set locking to strict. Strict locking means that the owner of an RCS file is not exempt from locking for checkin. `-mREV:MSG' Replace the log message of revision REV with MSG. `-NNAME[:[REV]]' Act like `-n', except override any previous assignment of NAME. `-nNAME[:[REV]]' Associate the symbolic name NAME with the branch or revision REV. It is normally better to use `cvs tag' or `cvs rtag' instead. Delete the symbolic name if both `:' and REV are omitted; otherwise, print an error message if NAME is already associated with another number. If REV is symbolic, it is expanded before association. A REV consisting of a branch number followed by a `.' stands for the current latest revision in the branch. A `:' with an empty REV stands for the current latest revision on the default branch, normally the trunk. For example, `rcs -nNAME: RCS/*' associates NAME with the current latest revision of all the named RCS files; this contrasts with `rcs -nNAME:$ RCS/*' which associates NAME with the revision numbers extracted from keyword strings in the corresponding working files. `-oRANGE' Useful, but dangerous, with CVS (see below). Deletes ("outdates") the revisions given by RANGE. 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 `REV1:REV2' means revisions REV1 to REV2 on the same branch, `:REV' means from the beginning of the branch containing REV up to and including REV, and `REV:' means from revision REV to the end of the branch containing REV. None of the outdated revisions may have branches or locks. Due to the way CVS handles branches REV cannot be specified symbolically if it is a branch. *Note Magic branch numbers::, for an explanation. Make sure that no-one has checked out a copy of the revision you outdate. Strange things will happen if he starts to edit it and tries to check it back in. For this reason, you should never use this option to take back a bogus commit unless you work alone. Instead, you should fix the file and commit a new revision. `-q' Run quietly; do not print diagnostics. `-sSTATE[:REV]' Useful with CVS. Set the state attribute of the revision REV to STATE. If REV is a branch number, assume the latest revision on that branch. If REV is omitted, assume the latest revision on the default branch. Any identifier is acceptable for STATE. A useful set of states is `Exp' (for experimental), `Stab' (for stable), and `Rel' (for released). By default, the state of a new revision is set to `Exp' when it is created. The state is visible in the output from CVS LOG (*note log::.), and in the `$Log: cvs.info-3,v $ output from CVS LOG (*note log::.), and in the `Revision 1.1 1995/12/19 09:21:39 deraadt output from CVS LOG (*note log::.), and in the `Initial revision output from CVS LOG (*note log::.), and in the `' and `$State: Exp $' keywords (*note Keyword substitution::.). `-t[FILE]' Useful with CVS. Write descriptive text from the contents of the named FILE into the RCS file, deleting the existing text. The FILE pathname may not begin with `-'. If FILE is omitted, obtain the text from standard input, terminated by end-of-file or by a line containing `.' by itself. Prompt for the text if interaction is possible; see `-I'. The descriptive text can be seen in the output from `cvs log' (*note log::.). `-t-STRING' Similar to `-tFILE'. Write descriptive text from the STRING into the RCS file, deleting the existing text. `-U' Probably useless with CVS. Used with bare RCS to set locking to non-strict. Non-strict locking means that the owner of a file need not lock a revision for checkin. `-u[REV]' Probably useless with CVS. With bare RCS, unlock the revision with number REV. If a branch is given, unlock the latest revision on that branch. If REV is omitted, remove the latest lock held by the caller. Normally, only the locker of a revision may unlock it. Somebody else unlocking a revision breaks the lock. This causes a mail message to be sent to the original locker. The message contains a commentary solicited from the breaker. The commentary is terminated by end-of-file or by a line containing `.' by itself. `-VN' Emulate RCS version N. Use -VN to make an RCS file acceptable to RCS version N by discarding information that would confuse version N. `-xSUFFIXES' Useless with CVS. Use SUFFIXES to characterize RCS files.  File: cvs.info, Node: admin examples, Prev: admin options, Up: admin admin examples -------------- Outdating is dangerous ...................... First, an example of how *not* to use the `admin' command. It is included to stress the fact that this command can be quite dangerous unless you know *exactly* what you are doing. The `-o' option can be used to "outdate" old revisions from the history file. If you are short on disc this option might help you. But think twice before using it--there is no way short of restoring the latest backup to undo this command! The next line is an example of a command that you would *not* like to execute. $ cvs admin -o:R_1_02 . The above command will delete all revisions up to, and including, the revision that corresponds to the tag R_1_02. But beware! If there are files that have not changed between R_1_02 and R_1_03 the file will have *the same* numerical revision number assigned to the tags R_1_02 and R_1_03. So not only will it be impossible to retrieve R_1_02; R_1_03 will also have to be restored from the tapes! Handling binary files ..................... If you use CVS to store binary files, where keyword strings (*note Keyword substitution::.) might accidentally appear inside the file, you should use `cvs admin -ko' to make sure that they are not modified automatically. Here is an example of how you can create a new file using the `-ko' flag: $ echo '$Id: cvs.info-3,v 1.1 1995/12/19 09:21:39 deraadt Exp $' > kotest $ cvs add -m"A test file" kotest $ cvs ci -m"First checkin; contains a keyword" kotest $ cvs admin -ko kotest $ rm kotest $ cvs update kotest When you check in the file `kotest' the keywords are expanded. (Try the above example, and do a `cat kotest' after every command!) The `cvs admin -ko' command sets the default keyword substitution method for this file, but it does not alter the working copy of the file that you have. The easiest way to get the unexpanded version of `kotest' is to remove it and check it out again. Comment leaders ............... If you use the `$Log: cvs.info-3,v $ If you use the `Revision 1.1 1995/12/19 09:21:39 deraadt If you use the `Initial revision If you use the `' keyword and you do not agree with the guess for comment leader that CVS has done, you can enforce your will with `cvs admin -c'. This might be suitable for `nroff' source: $ cvs admin -c'.\" ' *.man $ rm *.man $ cvs update The two last steps are to make sure that you get the versions with correct comment leaders in your working files.  File: cvs.info, Node: checkout, Next: commit, Prev: admin, Up: Invoking CVS checkout--Check out sources for editing ======================================= * Synopsis: checkout [options] modules... * Requires: repository. * Changes: working directory. * Synonyms: co, get Make a working directory containing copies of the source files specified by MODULES. You must execute `checkout' before using most of the other CVS commands, since most of them operate on your working directory. The MODULES part of the command are either symbolic names for some collection of source directories and files, or paths to directories or files in the repository. The symbolic names are defined in the `modules' file. *Note modules::. Depending on the modules you specify, `checkout' may recursively create directories and populate them with the appropriate source files. You can then edit these source files at any time (regardless of whether other software developers are editing their own copies of the sources); update them to include new changes applied by others to the source repository; or commit your work as a permanent change to the source repository. Note that `checkout' is used to create directories. The top-level directory created is always added to the directory where `checkout' is invoked, and usually has the same name as the specified module. In the case of a module alias, the created sub-directory may have a different name, but you can be sure that it will be a sub-directory, and that `checkout' will show the relative path leading to each file as it is extracted into your private work area (unless you specify the `-Q' global option). Running `checkout' on a directory that was already built by a prior `checkout' is also permitted, and has the same effect as specifying the `-d' option to the `update' command, that is, any new directories that have been created in the repository will appear in your work area. *Note update::. * Menu: * checkout options:: checkout options * checkout examples:: checkout examples  File: cvs.info, Node: checkout options, Next: checkout examples, Up: checkout checkout options ---------------- These standard options are supported by `checkout' (*note Common options::., for a complete description of them): `-D DATE' Use the most recent revision no later than DATE. This option is sticky, and implies `-P'. `-f' Only useful with the `-D DATE' or `-r TAG' flags. If no matching revision is found, retrieve the most recent revision (instead of ignoring the file). `-k KFLAG' Process RCS keywords according to KFLAG. See co(1). This option is sticky; future updates of this file in this working directory will use the same KFLAG. The `status' command can be viewed to see the sticky options. *Note status::. `-l' Local; run only in current working directory. `-n' Do not run any checkout program (as specified with the `-o' option in the modules file; *note modules::.). `-P' Prune empty directories. `-p' Pipe files to the standard output. `-r TAG' Use revision TAG. This option is sticky, and implies `-P'. In addition to those, you can use these special command options with `checkout': `-A' Reset any sticky tags, dates, or `-k' options. (If you get a working file using one of the `-r', `-D', or `-k' options, CVS remembers the corresponding tag, date, or KFLAG and continues using it for future updates; use the `-A' option to make CVS forget these specifications, and retrieve the `head' revision of the file). `-c' Copy the module file, sorted, to the standard output, instead of creating or modifying any files or directories in your working directory. `-d DIR' Create a directory called DIR for the working files, instead of using the module name. Unless you also use `-N', the paths created under DIR will be as short as possible. `-j TAG' Merge the changes made between the resulting revision and the revision that it is based on (e.g., if TAG refers to a branch, CVS will merge all changes made on that branch into your working file). With two `-j TAG' options, CVS will merge in the changes between the two respective revisions. This can be used to undo changes made between two revisions (*note Merging two revisions::.) in your working copy, or to move changes between different branches. In addition, each -j option can contain an optional date specification which, when used with branches, can limit the chosen revision to one within a specific date. An optional date is specified by adding a colon (:) to the tag. An example might be what `import' tells you to do when you have just imported sources that have conflicts with local changes: $ cvs checkout -jTAG:yesterday -jTAG module `-N' Only useful together with `-d DIR'. With this option, CVS will not shorten module paths in your working directory. (Normally, CVS shortens paths as much as possible when you specify an explicit target directory). `-s' Like `-c', but include the status of all modules, and sort it by the status string. *Note modules::, for info about the `-s' option that is used inside the modules file to set the module status.  File: cvs.info, Node: checkout examples, Prev: checkout options, Up: checkout checkout examples ----------------- Get a copy of the module `tc': $ cvs checkout tc Get a copy of the module `tc' as it looked one day ago: $ cvs checkout -D yesterday tc  File: cvs.info, Node: commit, Next: diff, Prev: checkout, Up: Invoking CVS commit--Check files into the repository ======================================= * Version 1.3 Synopsis: commit [-lnR] [-m 'log_message' | -f file] [-r revision] [files...] * Version 1.3.1 Synopsis: commit [-lnRf] [-m 'log_message' | -F file] [-r revision] [files...] * Requires: working directory, repository. * Changes: repository. * Synonym: ci *Warning:* The `-f FILE' option will probably be renamed to `-F FILE', and `-f' will be given a new behavior in future releases of CVS. Use `commit' when you want to incorporate changes from your working source files into the source repository. If you don't specify particular files to commit, all of the files in your working current directory are examined. `commit' is careful to change in the repository only those files that you have really changed. By default (or if you explicitly specify the `-R' option), files in subdirectories are also examined and committed if they have changed; you can use the `-l' option to limit `commit' to the current directory only. `commit' verifies that the selected files are up to date with the current revisions in the source repository; it will notify you, and exit without committing, if any of the specified files must be made current first with `update' (*note update::.). `commit' does not call the `update' command for you, but rather leaves that for you to do when the time is right. When all is well, an editor is invoked to allow you to enter a log message that will be written to one or more logging programs (*note modules::., and *note loginfo::.) and placed in the RCS history file inside the repository. This log message can be retrieved with the `log' command; *Note log::. You can specify the log message on the command line with the `-m MESSAGE' option, and thus avoid the editor invocation, or use the `-f FILE' option to specify that the argument file contains the log message. * Menu: * commit options:: commit options * commit examples:: commit examples  File: cvs.info, Node: commit options, Next: commit examples, Up: commit commit options -------------- These standard options are supported by `commit' (*note Common options::., for a complete description of them): `-l' Local; run only in current working directory. `-n' Do not run any module program. `-R' Commit directories recursively. This is on by default. `-r REVISION' Commit to REVISION. REVISION must be either a branch, or a revision on the main trunk that is higher than any existing revision number. You cannot commit to a specific revision on a branch. `commit' also supports these options: `-F FILE' This option is present in CVS releases 1.3-s3 and later. Read the log message from FILE, instead of invoking an editor. `-f' This option is present in CVS 1.3-s3 and later releases of CVS. Note that this is not the standard behavior of the `-f' option as defined in *Note Common options::. Force CVS to commit a new revision even if you haven't made any changes to the file. If the current revision of FILE is 1.7, then the following two commands are equivalent: $ cvs commit -f FILE $ cvs commit -r 1.8 FILE `-f FILE' This option is present in CVS releases 1.3, 1.3-s1 and 1.3-s2. Note that this is not the standard behavior of the `-f' option as defined in *Note Common options::. Read the log message from FILE, instead of invoking an editor. `-m MESSAGE' Use MESSAGE as the log message, instead of invoking an editor.  File: cvs.info, Node: commit examples, Prev: commit options, Up: commit commit examples --------------- New major release number ........................ When you make a major release of your product, you might want the revision numbers to track your major release number. You should normally not care about the revision numbers, but this is a thing that many people want to do, and it can be done without doing any harm. To bring all your files up to the RCS revision 3.0 (including those that haven't changed), you might do: $ cvs commit -r 3.0 Note that it is generally a bad idea to try to make the RCS revision number equal to the current release number of your product. You should think of the revision number as an internal number that the CVS package maintains, and that you generally never need to care much about. Using the `tag' and `rtag' commands you can give symbolic names to the releases instead. *Note tag:: and *Note rtag::. Note that the number you specify with `-r' must be larger than any existing revision number. That is, if revision 3.0 exists, you cannot `cvs commit -r 1.3'. Committing to a branch ...................... You can commit to a branch revision (one that has an even number of dots) with the `-r' option. To create a branch revision, use the `-b' option of the `rtag' or `tag' commands (*note tag::. or *note rtag::.). Then, either `checkout' or `update' can be used to base your sources on the newly created branch. From that point on, all `commit' changes made within these working sources will be automatically added to a branch revision, thereby not disturbing main-line development in any way. For example, if you had to create a patch to the 1.2 version of the product, even though the 2.0 version is already under development, you might do: $ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module $ cvs checkout -r FCS1_2_Patch product_module $ cd product_module [[ hack away ]] $ cvs commit This works automatically since the `-r' option is sticky. Creating the branch after editing ................................. Say you have been working on some extremely experimental software, based on whatever revision you happened to checkout last week. If others in your group would like to work on this software with you, but without disturbing main-line development, you could commit your change to a new branch. Others can then checkout your experimental stuff and utilize the full benefit of CVS conflict resolution. The scenario might look like: [[ hacked sources are present ]] $ cvs tag -b EXPR1 $ cvs update -r EXPR1 $ cvs commit The `update' command will make the `-r EXPR1' option sticky on all files. Note that your changes to the files will never be removed by the `update' command. The `commit' will automatically commit to the correct branch, because the `-r' is sticky. You could also do like this: [[ hacked sources are present ]] $ cvs tag -b EXPR1 $ cvs commit -r EXPR1 but then, only those files that were changed by you will have the `-r EXPR1' sticky flag. If you hack away, and commit without specifying the `-r EXPR1' flag, some files may accidentally end up on the main trunk. To work with you on the experimental change, others would simply do $ cvs checkout -r EXPR1 whatever_module  File: cvs.info, Node: diff, Next: export, Prev: commit, Up: Invoking CVS diff--Run diffs between revisions ================================= * Synopsis: diff [-l] [rcsdiff_options] [[-r rev1 | -D date1] [-r rev2 | -D date2]] [files...] * Requires: working directory, repository. * Changes: nothing. The `diff' command is used to compare different revisions of files. The default action is to compare your working files with the revisions they were based on, and report any differences that are found. If any file names are given, only those files are compared. If any directories are given, all files under them will be compared. The exit status will be 0 if no differences were found, 1 if some differences were found, and 2 if any error occurred. * Menu: * diff options:: diff options * diff examples:: diff examples  File: cvs.info, Node: diff options, Next: diff examples, Up: diff diff options ------------ These standard options are supported by `diff' (*note Common options::., for a complete description of them): `-D DATE' Use the most recent revision no later than DATE. See `-r' for how this affects the comparison. CVS can be configured to pass the `-D' option through to `rcsdiff' (which in turn passes it on to `diff'. GNU diff uses `-D' as a way to put `cpp'-style `#define' statements around the output differences. There is no way short of testing to figure out how CVS was configured. In the default configuration CVS will use the `-D DATE' option. `-k KFLAG' Process RCS keywords according to KFLAG. See co(1). `-l' Local; run only in current working directory. `-R' Examine directories recursively. This option is on by default. `-r TAG' Compare with revision TAG. Zero, one or two `-r' options can be present. With no `-r' option, the working file will be compared with the revision it was based on. With one `-r', that revision will be compared to your current working file. With two `-r' options those two revisions will be compared (and your working file will not affect the outcome in any way). One or both `-r' options can be replaced by a `-D DATE' option, described above. Any other options that are found are passed through to `rcsdiff', which in turn passes them to `diff'. The exact meaning of the options depends on which `diff' you are using. The long options introduced in GNU diff 2.0 are not yet supported in CVS. See the documentation for your `diff' to see which options are supported.  File: cvs.info, Node: diff examples, Prev: diff options, Up: diff diff examples ------------- The following line produces a Unidiff (`-u' flag) between revision 1.14 and 1.19 of `backend.c'. Due to the `-kk' flag no keywords are substituted, so differences that only depend on keyword substitution are ignored. $ cvs diff -kk -u -r 1.14 -r 1.19 backend.c Suppose the experimental branch EXPR1 was based on a set of files tagged RELEASE_1_0. To see what has happened on that branch, the following can be used: $ cvs diff -r RELEASE_1_0 -r EXPR1 A command like this can be used to produce a context diff between two releases: $ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs If you are maintaining ChangeLogs, a command like the following just before you commit your changes may help you write the ChangeLog entry. All local modifications that have not yet been committed will be printed. $ cvs diff -u | less  File: cvs.info, Node: export, Next: history, Prev: diff, Up: Invoking CVS export--Export sources from CVS, similar to checkout ==================================================== * Synopsis: export [-flNnQq] -r rev|-D date [-d dir] module... * Requires: repository. * Changes: current directory. This command is a variant of `checkout'; use it when you want a copy of the source for module without the CVS administrative directories. For example, you might use `export' to prepare source for shipment off-site. This command requires that you specify a date or tag (with `-D' or `-r'), so that you can count on reproducing the source you ship to others. The keyword substitution option `-kv' is always set when export is used. This causes any RCS keywords to be expanded such that an import done at some other site will not lose the keyword revision information. There is no way to override this. Note that this breaks the `ident' command (which is part of the RCS suite--see ident(1)) which looks for RCS keyword strings. If you want to be able to use `ident' you must use `checkout' instead. * Menu: * export options:: export options  File: cvs.info, Node: export options, Up: export export options -------------- These standard options are supported by `export' (*note Common options::., for a complete description of them): `-D DATE' Use the most recent revision no later than DATE. `-f' If no matching revision is found, retrieve the most recent revision (instead of ignoring the file). `-l' Local; run only in current working directory. `-n' Do not run any checkout program. `-R' Export directories recursively. This is on by default. `-r TAG' Use revision TAG. In addition, these options (that are common to `checkout' and `export') are also supported: `-d DIR' Create a directory called DIR for the working files, instead of using the module name. Unless you also use `-N', the paths created under DIR will be as short as possible. `-N' Only useful together with `-d DIR'. With this option, CVS will not shorten module paths in your working directory. (Normally, CVS shortens paths as much as possible when you specify an explicit target directory.)  File: cvs.info, Node: history, Next: import, Prev: export, Up: Invoking CVS history--Show status of files and users ======================================= * Synopsis: history [-report] [-flags] [-options args] [files...] * Requires: the file `$CVSROOT/CVSROOT/history' * Changes: nothing. CVS can keep a history file that tracks each use of the `checkout', `commit', `rtag', `update', and `release' commands. You can use `history' to display this information in various formats. Logging must be enabled by creating the file `$CVSROOT/CVSROOT/history'. *Warning:* `history' uses `-f', `-l', `-n', and `-p' in ways that conflict with the normal use inside CVS (*note Common options::.). * Menu: * history options:: history options  File: cvs.info, Node: history options, Up: history history options --------------- Several options (shown above as `-report') control what kind of report is generated: `-c' Report on each time commit was used (i.e., each time the repository was modified). `-e' Everything (all record types); equivalent to specifying `-xMACFROGWUT'. `-m MODULE' Report on a particular module. (You can meaningfully use `-m' more than once on the command line.) `-o' Report on checked-out modules. `-T' Report on all tags. `-x TYPE' Extract a particular set of record types TYPE from the CVS history. The types are indicated by single letters, which you may specify in combination. Certain commands have a single record type: `F' release `O' checkout `T' rtag One of four record types may result from an update: `C' A merge was necessary but collisions were detected (requiring manual merging). `G' A merge was necessary and it succeeded. `U' A working file was copied from the repository. `W' The working copy of a file was deleted during update (because it was gone from the repository). One of three record types results from commit: `A' A file was added for the first time. `M' A file was modified. `R' A file was removed. The options shown as `-flags' constrain or expand the report without requiring option arguments: `-a' Show data for all users (the default is to show data only for the user executing `history'). `-l' Show last modification only. `-w' Show only the records for modifications done from the same working directory where `history' is executing. The options shown as `-options ARGS' constrain the report based on an argument: `-b STR' Show data back to a record containing the string STR in either the module name, the file name, or the repository path. `-D DATE' Show data since DATE. This is slightly different from the normal use of `-D DATE', which selects the newest revision older than DATE. `-p REPOSITORY' Show data for a particular source repository (you can specify several `-p' options on the same command line). `-r REV' Show records referring to revisions since the revision or tag named REV appears in individual RCS files. Each RCS file is searched for the revision or tag. `-t TAG' Show records since tag TAG was last added to the the history file. This differs from the `-r' flag above in that it reads only the history file, not the RCS files, and is much faster. `-u NAME' Show records for user NAME.  File: cvs.info, Node: import, Next: log, Prev: history, Up: Invoking CVS import--Import sources into CVS, using vendor branches ====================================================== * Synopsis: import [-options] repository vendortag releasetag... * Requires: Repository, source distribution directory. * Changes: repository. Use `import' to incorporate an entire source distribution from an outside source (e.g., a source vendor) into your source repository directory. You can use this command both for initial creation of a repository, and for wholesale updates to the module from the outside source. *Note Tracking sources::, for a discussion on this subject. The REPOSITORY argument gives a directory name (or a path to a directory) under the CVS root directory for repositories; if the directory did not exist, import creates it. When you use import for updates to source that has been modified in your source repository (since a prior import), it will notify you of any files that conflict in the two branches of development; use `checkout -j' to reconcile the differences, as import instructs you to do. By default, certain file names are ignored during `import': names associated with CVS administration, or with other common source control systems; common names for patch files, object files, archive files, and editor backup files; and other names that are usually artifacts of assorted utilities. Currently, the default list of ignored files includes files matching these names: RCSLOG RCS SCCS CVS* cvslog.* tags TAGS .make.state .nse_depinfo *~ #* .#* ,* *.old *.bak *.BAK *.orig *.rej .del-* *.a *.o *.so *.Z *.elc *.ln core If the file `$CVSROOT/CVSROOT/cvsignore' exists, any files whose names match the specifications in that file will also be ignored. If the file `$CVSROOT/CVSROOT/cvswrappers' exists, any file whose names match the specifications in that file will be treated as packages and the appropriate filtering will be performed on the file/directory before being imported, *Note Wrappers::. The outside source is saved in a first-level RCS branch, by default 1.1.1. Updates are leaves of this branch; for example, files from the first imported collection of source will be revision 1.1.1.1, then files from the first imported update will be revision 1.1.1.2, and so on. At least three arguments are required. REPOSITORY is needed to identify the collection of source. VENDORTAG is a tag for the entire branch (e.g., for 1.1.1). You must also specify at least one RELEASETAG to identify the files at the leaves created each time you execute `import'. * Menu: * import options:: import options * import examples:: import examples  File: cvs.info, Node: import options, Next: import examples, Up: import import options -------------- This standard option is supported by `import' (*note Common options::., for a complete description): `-m MESSAGE' Use MESSAGE as log information, instead of invoking an editor. There are three additional special options. `-b BRANCH' Specify a first-level branch other than 1.1.1. Unless the `-b BRANCH' flag is given, revisions will *always* be made to the branch 1.1.1--even if a VENDORTAG that matches another branch is given! What happens in that case, is that the tag will be reset to 1.1.1. Warning: This behavior might change in the future. `-k SUBST' Indicate the RCS keyword expansion mode desired. This setting will apply to all files created during the import, but not to any files that previously existed in the repository. See co(1) for a complete list of valid `-k' settings. If you are checking in sources that contain RCS keywords, and you wish those keywords to remain intact, use the `-ko' flag when importing the files. This setting indicates that no keyword expansion is to be performed by RCS when checking files out. It is also useful for checking in binaries. `-I NAME' Specify file names that should be ignored during import. You can use this option repeatedly. To avoid ignoring any files at all (even those ignored by default), specify `-I !'. NAME can be a file name pattern of the same type that you can specify in the `.cvsignore' file. *Note cvsignore::. `-W SPEC' Specify file names that should be filtered during import. You can use this option repeatedly. SPEC can be a file name pattern of the same type that you can specify in the `.cvswrappers' file. *Note Wrappers::.  File: cvs.info, Node: import examples, Prev: import options, Up: import import examples --------------- *Note Tracking sources::, and *Note From files::.  File: cvs.info, Node: log, Next: rdiff, Prev: import, Up: Invoking CVS log--Print out 'rlog' information for files =========================================== * Synopsis: log [-l] rlog-options [files...] * Requires: repository, working directory. * Changes: nothing. * Synonym: rlog Display log information for files. `log' calls the RCS utility `rlog', which prints all available information about the RCS history file. This includes the location of the RCS file, the "head" revision (the latest revision on the trunk), all symbolic names (tags) and some other things. For each revision, the revision number, the author, the number of lines added/deleted and the log message are printed. All times are displayed in Coordinated Universal Time (UTC). (Other parts of CVS print times in the local timezone). * Menu: * log options:: log options * log examples:: log examples  File: cvs.info, Node: log options, Next: log examples, Up: log log options ----------- Only one option is interpreted by CVS and not passed on to `rlog': `-l' Local; run only in current working directory. (Default is to run recursively). By default, `rlog' prints all information that is available. All other options (including those that normally behave differently) are passed through to `rlog' and restrict the output. See rlog(1) for a complete description of options. This incomplete list (which is a slightly edited extract from rlog(1)) lists all options that are useful in conjunction with CVS. *Please note:* There can be no space between the option and its argument, since `rlog' parses its options in a different way than CVS. `-b' Print information about the revisions on the default branch, normally the highest branch on the trunk. `-dDATES' Print information about revisions with a checkin date/time in the range given by the semicolon-separated list of dates. The following table explains the available range formats: `D1D1' Select the revisions that were deposited between D1 and D2 inclusive. `' Select all revisions dated D or earlier. `D<' `>D' Select all revisions dated D or later. `D' Select the single, latest revision dated D or earlier. The date/time strings D, D1, and D2 are in the free format explained in co(1). Quoting is normally necessary, especially for < and >. Note that the separator is a semicolon (;). `-h' Print only the RCS pathname, working pathname, head, default branch, access list, locks, symbolic names, and suffix. `-N' Do not print the list of tags for this file. This option can be very useful when your site uses a lot of tags, so rather than "more"'ing over 3 pages of tag information, the log information is presented without tags at all. `-R' Print only the name of the RCS history file. `-rREVISIONS' Print information about revisions given in the comma-separated list REVISIONS of revisions and ranges. The following table explains the available range formats: `REV1:REV2' Revisions REV1 to REV2 (which must be on the same branch). `:REV' Revisions from the beginning of the branch up to and including REV. `REV:' Revisions starting with REV to the end of the branch containing REV. `BRANCH' An argument that is a branch means all revisions on that branch. You can unfortunately not specify a symbolic branch here. You must specify the numeric branch number. *Note Magic branch numbers::, for an explanation. `BRANCH1:BRANCH2' A range of branches means all revisions on the branches in that range. `BRANCH.' The latest revision in BRANCH. A bare `-r' with no revisions means the latest revision on the default branch, normally the trunk. `-sSTATES' Print information about revisions whose state attributes match one of the states given in the comma-separated list STATES. `-t' Print the same as `-h', plus the descriptive text. `-wLOGINS' Print information about revisions checked in by users with login names appearing in the comma-separated list LOGINS. If LOGINS is omitted, the user's login is assumed. `rlog' prints the intersection of the revisions selected with the options `-d', `-l', `-s', and `-w', intersected with the union of the revisions selected by `-b' and `-r'.  File: cvs.info, Node: log examples, Prev: log options, Up: log log examples ------------ Contributed examples are gratefully accepted.  File: cvs.info, Node: rdiff, Next: release, Prev: log, Up: Invoking CVS rdiff--'patch' format diffs between releases ============================================ * rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules... * Requires: repository. * Changes: nothing. * Synonym: patch Builds a Larry Wall format patch(1) file between two releases, that can be fed directly into the patch program to bring an old release up-to-date with the new release. (This is one of the few CVS commands that operates directly from the repository, and doesn't require a prior checkout.) The diff output is sent to the standard output device. You can specify (using the standard `-r' and `-D' options) any combination of one or two revisions or dates. If only one revision or date is specified, the patch file reflects differences between that revision or date and the current head revisions in the RCS file. Note that if the software release affected is contained in more than one directory, then it may be necessary to specify the `-p' option to the patch command when patching the old sources, so that patch is able to find the files that are located in other directories. * Menu: * rdiff options:: rdiff options * rdiff examples:: rdiff examples  File: cvs.info, Node: rdiff options, Next: rdiff examples, Up: rdiff rdiff options ------------- These standard options are supported by `rdiff' (*note Common options::., for a complete description of them): `-D DATE' Use the most recent revision no later than DATE. `-f' If no matching revision is found, retrieve the most recent revision (instead of ignoring the file). `-l' Local; don't descend subdirectories. `-r TAG' Use revision TAG. In addition to the above, these options are available: `-c' Use the context diff format. This is the default format. `-s' Create a summary change report instead of a patch. The summary includes information about files that were changed or added between the releases. It is sent to the standard output device. This is useful for finding out, for example, which files have changed between two dates or revisions. `-t' A diff of the top two revisions is sent to the standard output device. This is most useful for seeing what the last change to a file was. `-u' Use the unidiff format for the context diffs. This option is not available if your diff does not support the unidiff format. Remember that old versions of the `patch' program can't handle the unidiff format, so if you plan to post this patch to the net you should probably not use `-u'. `-V VN' Expand RCS keywords according to the rules current in RCS version VN (the expansion format changed with RCS version 5).  File: cvs.info, Node: rdiff examples, Prev: rdiff options, Up: rdiff rdiff examples -------------- Suppose you receive mail from foo@bar.com asking for an update from release 1.2 to 1.4 of the tc compiler. You have no such patches on hand, but with CVS that can easily be fixed with a command such as this: $ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \ $$ Mail -s 'The patches you asked for' foo@bar.com Suppose you have made release 1.3, and forked a branch called `R_1_3fix' for bugfixes. `R_1_3_1' corresponds to release 1.3.1, which was made some time ago. Now, you want to see how much development has been done on the branch. This command can be used: $ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name cvs rdiff: Diffing module-name File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6 File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4 File bar.h,v changed from revision 1.29.2.1 to 1.2  File: cvs.info, Node: release, Next: remove, Prev: rdiff, Up: Invoking CVS release--Indicate that a Module is no longer in use =================================================== * release [-dQq] modules... * Requires: Working directory. * Changes: Working directory, history log. This command is meant to safely cancel the effect of `cvs checkout'. Since CVS doesn't lock files, it isn't strictly necessary to use this command. You can always simply delete your working directory, if you like; but you risk losing changes you may have forgotten, and you leave no trace in the CVS history file (*note history file::.) that you've abandoned your checkout. Use `cvs release' to avoid these problems. This command checks that no uncommitted changes are present; that you are executing it from immediately above a CVS working directory; and that the repository recorded for your files is the same as the repository defined in the module database. If all these conditions are true, `cvs release' leaves a record of its execution (attesting to your intentionally abandoning your checkout) in the CVS history log. * Menu: * release options:: release options * release output:: release options * release examples:: release examples  File: cvs.info, Node: release options, Next: release output, Up: release release options --------------- The `release' command supports one command option: `-d' Delete your working copy of the file if the release succeeds. If this flag is not given your files will remain in your working directory. *Warning:* The `release' command uses `rm -r `module'' to delete your file. This has the very serious side-effect that any directory that you have created inside your checked-out sources, and not added to the repository (using the `add' command; *note add::.) will be silently deleted--even if it is non-empty!