home *** CD-ROM | disk | FTP | other *** search
/ Geek Gadgets 1 / ADE-1.bin / ade-bin / info / cvs.info-4 < prev    next >
Encoding:
GNU Info File  |  1996-10-13  |  49.0 KB  |  1,380 lines
  1. This is Info file cvs.info, produced by Makeinfo-1.64 from the input
  2. file /ade-source/fsf/cvs/doc/cvs.texinfo.
  3.  
  4.    Copyright (C) 1992, 1993 Signum Support AB Copyright (C) 1993, 1994
  5. Free Software Foundation, Inc.
  6.  
  7.    Permission is granted to make and distribute verbatim copies of this
  8. manual provided the copyright notice and this permission notice are
  9. preserved on all copies.
  10.  
  11.    Permission is granted to copy and distribute modified versions of
  12. this manual under the conditions for verbatim copying, provided also
  13. that the section entitled "GNU General Public License" is included
  14. exactly as in the original, and provided that the entire resulting
  15. derived work is distributed under the terms of a permission notice
  16. identical to this one.
  17.  
  18.    Permission is granted to copy and distribute translations of this
  19. manual into another language, under the above conditions for modified
  20. versions, except that the section entitled "GNU General Public License"
  21. and this permission notice may be included in translations approved by
  22. the Free Software Foundation instead of in the original English.
  23.  
  24. 
  25. File: cvs.info,  Node: Common options,  Next: admin,  Prev: Global options,  Up: Invoking CVS
  26.  
  27. Common command options
  28. ======================
  29.  
  30.    This section describes the `command_options' that are available
  31. across several CVS commands.  These options are always given to the
  32. right of `cvs_command'. Not all commands support all of these options;
  33. each option is only supported for commands where it makes sense.
  34. However, when a command has one of these options you can almost always
  35. count on the same behavior of the option as in other commands.  (Other
  36. command options, which are listed with the individual commands, may have
  37. different behavior from one CVS command to the other).
  38.  
  39.    *Warning:* the `history' command is an exception; it supports many
  40. options that conflict even with these standard options.
  41.  
  42. `-D DATE_SPEC'
  43.      Use the most recent revision no later than DATE_SPEC.  DATE_SPEC
  44.      is a single argument, a date description specifying a date in the
  45.      past.
  46.  
  47.      The specification is "sticky" when you use it to make a private
  48.      copy of a source file; that is, when you get a working file using
  49.      `-D', CVS records the date you specified, so that further updates
  50.      in the same directory will use the same date (for more information
  51.      on sticky tags/dates, *note Sticky tags::.).
  52.  
  53.      A wide variety of date formats are supported by CVS.  The
  54.      DATE_SPEC is interpreted as being in the local timezone, unless a
  55.      specific timezone is specified.  Examples of valid date
  56.      specifications include:
  57.  
  58.                               1 month ago
  59.                               2 hours ago
  60.                               400000 seconds ago
  61.                               last year
  62.                               last Monday
  63.                               yesterday
  64.                               a fortnight ago
  65.                               3/31/92 10:00:07 PST
  66.                               January 23, 1987 10:05pm
  67.                               22:00 GMT
  68.  
  69.      `-D' is available with the `checkout', `diff', `export', `history',
  70.      `rdiff', `rtag', and `update' commands.  (The `history' command
  71.      uses this option in a slightly different way; *note history
  72.      options::.).  Note that when specifying a date like `3/31/92' it is
  73.      `MONTH/DAY/YEAR'.  So `1/4/96' is January 4, not March 1.
  74.  
  75.      Remember to quote the argument to the `-D' flag so that your shell
  76.      doesn't interpret spaces as argument separators.  A command using
  77.      the `-D' flag can look like this:
  78.  
  79.           $ cvs diff -D "1 hour ago" cvs.texinfo
  80.  
  81. `-f'
  82.      When you specify a particular date or tag to CVS commands, they
  83.      normally ignore files that do not contain the tag (or did not
  84.      exist prior to the date) that you specified.  Use the `-f' option
  85.      if you want files retrieved even when there is no match for the
  86.      tag or date.  (The most recent revision of the file will be used).
  87.  
  88.      `-f' is available with these commands: `checkout', `export',
  89.      `rdiff', `rtag', and `update'.
  90.  
  91.      *Warning:*  The `commit' command also has a `-f' option, but it
  92.      has a different behavior for that command.  *Note commit options::.
  93.  
  94. `-H'
  95.      Help; describe the options available for this command.  This is
  96.      the only option supported for all CVS commands.
  97.  
  98. `-k KFLAG'
  99.      Alter the default RCS processing of keywords.  *Note Keyword
  100.      substitution::, for the meaning of KFLAG.  Your KFLAG
  101.      specification is "sticky" when you use it to create a private copy
  102.      of a source file; that is, when you use this option with the
  103.      `checkout' or `update' commands, CVS associates your selected
  104.      KFLAG with the file, and continues to use it with future update
  105.      commands on the same file until you specify otherwise.
  106.  
  107.      The `-k' option is available with the `add', `checkout', `diff' and
  108.      `update' commands.
  109.  
  110. `-l'
  111.      Local; run only in current working directory, rather than
  112.      recursing through subdirectories.
  113.  
  114.      *Warning:* this is not the same as the overall `cvs -l' option,
  115.      which you can specify to the left of a cvs command!
  116.  
  117.      Available with the following commands: `checkout', `commit',
  118.      `diff', `export', `log', `remove', `rdiff', `rtag', `status',
  119.      `tag', and `update'.
  120.  
  121. `-m MESSAGE'
  122.      Use MESSAGE as log information, instead of invoking an editor.
  123.  
  124.      Available with the following commands: `add', `commit' and
  125.      `import'.
  126.  
  127. `-n'
  128.      Do not run any checkout/commit/tag program.  (A program can be
  129.      specified to run on each of these activities, in the modules
  130.      database (*note modules::.); this option bypasses it).
  131.  
  132.      *Warning:* this is not the same as the overall `cvs -n' option,
  133.      which you can specify to the left of a cvs command!
  134.  
  135.      Available with the `checkout', `commit', `export', and `rtag'
  136.      commands.
  137.  
  138. `-P'
  139.      Prune (remove) directories that are empty after being updated, on
  140.      `checkout', or `update'.  Normally, an empty directory (one that
  141.      is void of revision-controlled files) is left alone.  Specifying
  142.      `-P' will cause these directories to be silently removed from your
  143.      checked-out sources.  This does not remove the directory from the
  144.      repository, only from your checked out copy.  Note that this
  145.      option is implied by the `-r' or `-D' options of `checkout' and
  146.      `export'.
  147.  
  148. `-p'
  149.      Pipe the files retrieved from the repository to standard output,
  150.      rather than writing them in the current directory.  Available with
  151.      the `checkout' and `update' commands.
  152.  
  153. `-W'
  154.      Specify file names that should be filtered.  You can use this
  155.      option repeatedly.  The spec can be a file name pattern of the
  156.      same type that you can specify in the `.cvswrappers' file.
  157.      Avaliable with the following commands: `import', and `update'.
  158.  
  159. `-r TAG'
  160.      Use the revision specified by the TAG argument instead of the
  161.      default "head" revision.  As well as arbitrary tags defined with
  162.      the `tag' or `rtag' command, two special tags are always
  163.      available: `HEAD' refers to the most recent version available in
  164.      the repository, and `BASE' refers to the revision you last checked
  165.      out into the current working directory.
  166.  
  167.      The tag specification is sticky when you use this with `checkout'
  168.      or `update' to make your own copy of a file: CVS remembers the tag
  169.      and continues to use it on future update commands, until you
  170.      specify otherwise (for more information on sticky tags/dates,
  171.      *note Sticky tags::.).  The tag can be either a symbolic or
  172.      numeric tag.  *Note Tags::.
  173.  
  174.      Specifying the `-q' global option along with the `-r' command
  175.      option is often useful, to suppress the warning messages when the
  176.      RCS history file does not contain the specified tag.
  177.  
  178.      *Warning:* this is not the same as the overall `cvs -r' option,
  179.      which you can specify to the left of a cvs command!
  180.  
  181.      `-r' is available with the `checkout', `commit', `diff',
  182.      `history', `export', `rdiff', `rtag', and `update' commands.
  183.  
  184. 
  185. File: cvs.info,  Node: admin,  Next: checkout,  Prev: Common options,  Up: Invoking CVS
  186.  
  187. admin--Administration front end for rcs
  188. =======================================
  189.  
  190.    * Requires: repository, working directory.
  191.  
  192.    * Changes: repository.
  193.  
  194.    * Synonym: rcs
  195.  
  196.    This is the CVS interface to assorted administrative RCS facilities,
  197. documented in rcs(1).  `admin' simply passes all its options and
  198. arguments to the `rcs' command; it does no filtering or other
  199. processing.  This command *does* work recursively, however, so extreme
  200. care should be used.
  201.  
  202.    If there is a group whose name matches a compiled in value which
  203. defaults to `cvsadmin', only members of that group can use `cvs admin'.
  204. To disallow `cvs admin' for all users, create a group with no users in
  205. it.
  206.  
  207. * Menu:
  208.  
  209. * admin options::               admin options
  210. * admin examples::              admin examples
  211.  
  212. 
  213. File: cvs.info,  Node: admin options,  Next: admin examples,  Up: admin
  214.  
  215. admin options
  216. -------------
  217.  
  218.    Not all valid `rcs' options are useful together with CVS.  Some even
  219. makes it impossible to use CVS until you undo the effect!
  220.  
  221.    This description of the available options is based on the `rcs(1)'
  222. man page, but modified to suit readers that are more interrested in CVS
  223. than RCS.
  224.  
  225. `-AOLDFILE'
  226.      Might not work together with CVS.  Append the access list of
  227.      OLDFILE to the access list of the RCS file.
  228.  
  229. `-aLOGINS'
  230.      Might not work together with CVS.  Append the login names
  231.      appearing in the comma-separated list LOGINS to the access list of
  232.      the RCS file.
  233.  
  234. `-b[REV]'
  235.      When used with bare RCS, this option sets the default branch to
  236.      REV; in CVS sticky tags (*note Sticky tags::.) are a better way to
  237.      decide which branch you want to work on.  With CVS, this option
  238.      can be used to control behavior with respect to the vendor branch.
  239.  
  240. `-cSTRING'
  241.      Useful with CVS.  Sets the comment leader to STRING.  The comment
  242.      leader is printed before every log message line generated by the
  243.      keyword `$Log$' (*note Keyword substitution::.).  This is useful
  244.      for programming languages without multi-line comments.  RCS
  245.      initially guesses the value of the comment leader from the file
  246.      name extension when the file is first committed.
  247.  
  248. `-e[LOGINS]'
  249.      Might not work together with CVS.  Erase the login names appearing
  250.      in the comma-separated list LOGINS from the access list of the RCS
  251.      file.  If LOGINS is omitted, erase the entire access list.
  252.  
  253. `-I'
  254.      Run interactively, even if the standard input is not a terminal.
  255.  
  256. `-i'
  257.      Useless with CVS.  When using bare RCS, this is used to create and
  258.      initialize a new RCS file, without depositing a revision.
  259.  
  260. `-kSUBST'
  261.      Useful with CVS.  Set the default keyword substitution to SUBST.
  262.      *Note Keyword substitution::.  Giving an explicit `-k' option to
  263.      `cvs update', `cvs export', or `cvs checkout' overrides this
  264.      default.
  265.  
  266. `-l[REV]'
  267.      Lock the revision with number REV.  If a branch is given, lock the
  268.      latest revision on that branch.  If REV is omitted, lock the
  269.      latest revision on the default branch.
  270.  
  271.      This can be used in conjunction with the `rcslock.pl' script in
  272.      the `contrib' directory of the CVS source distribution to provide
  273.      reserved checkouts (where only one user can be editing a given
  274.      file at a time).  See the comments in that file for details (and
  275.      see the `README' file in that directory for disclaimers about the
  276.      unsupported nature of contrib).  According to comments in that
  277.      file, locking must set to strict (which is the default).
  278.  
  279. `-L'
  280.      Set locking to strict.  Strict locking means that the owner of an
  281.      RCS file is not exempt from locking for checkin.  For use with
  282.      CVS, strict locking must be set; see the discussion under the `-l'
  283.      option above.
  284.  
  285. `-mREV:MSG'
  286.      Replace the log message of revision REV with MSG.
  287.  
  288. `-NNAME[:[REV]]'
  289.      Act like `-n', except override any previous assignment of NAME.
  290.  
  291. `-nNAME[:[REV]]'
  292.      Associate the symbolic name NAME with the branch or revision REV.
  293.      It is normally better to use `cvs tag' or `cvs rtag' instead.
  294.      Delete the symbolic name if both `:' and REV are omitted;
  295.      otherwise, print an error message if NAME is already associated
  296.      with another number.  If REV is symbolic, it is expanded before
  297.      association.  A REV consisting of a branch number followed by a
  298.      `.' stands for the current latest revision in the branch.  A `:'
  299.      with an empty REV stands for the current latest revision on the
  300.      default branch, normally the trunk.  For example, `rcs -nNAME:
  301.      RCS/*' associates NAME with the current latest revision of all the
  302.      named RCS files; this contrasts with `rcs -nNAME:$ RCS/*' which
  303.      associates NAME with the revision numbers extracted from keyword
  304.      strings in the corresponding working files.
  305.  
  306. `-oRANGE'
  307.      Potentially useful, but dangerous, with CVS (see below).  Deletes
  308.      ("outdates") the revisions given by RANGE.  A range consisting of
  309.      a single revision number means that revision.  A range consisting
  310.      of a branch number means the latest revision on that branch.  A
  311.      range of the form `REV1:REV2' means revisions REV1 to REV2 on the
  312.      same branch, `:REV' means from the beginning of the branch
  313.      containing REV up to and including REV, and `REV:' means from
  314.      revision REV to the end of the branch containing REV.  None of the
  315.      outdated revisions may have branches or locks.
  316.  
  317.      Due to the way CVS handles branches REV cannot be specified
  318.      symbolically if it is a branch.  *Note Magic branch numbers::, for
  319.      an explanation.
  320.  
  321.      Make sure that no-one has checked out a copy of the revision you
  322.      outdate.  Strange things will happen if he starts to edit it and
  323.      tries to check it back in.  For this reason, this option is not a
  324.      good way to take back a bogus commit; commit a new revision
  325.      undoing the bogus change instead (*note Merging two revisions::.).
  326.  
  327. `-q'
  328.      Run quietly; do not print diagnostics.
  329.  
  330. `-sSTATE[:REV]'
  331.      Useful with CVS.  Set the state attribute of the revision REV to
  332.      STATE.  If REV is a branch number, assume the latest revision on
  333.      that branch.  If REV is omitted, assume the latest revision on the
  334.      default branch.  Any identifier is acceptable for STATE.  A useful
  335.      set of states is `Exp' (for experimental), `Stab' (for stable),
  336.      and `Rel' (for released).  By default, the state of a new revision
  337.      is set to `Exp' when it is created.  The state is visible in the
  338.      output from CVS LOG (*note log::.), and in the `$Log$' and
  339.      `$State$' keywords (*note Keyword substitution::.).  Note that CVS
  340.      uses the `dead' state for its own purposes; to take a file to or
  341.      from the `dead' state use commands like `cvs remove' and `cvs
  342.      add', not `cvs admin -s'.
  343.  
  344. `-t[FILE]'
  345.      Useful with CVS.  Write descriptive text from the contents of the
  346.      named FILE into the RCS file, deleting the existing text.  The
  347.      FILE pathname may not begin with `-'.  If FILE is omitted, obtain
  348.      the text from standard input, terminated by end-of-file or by a
  349.      line containing `.' by itself.  Prompt for the text if interaction
  350.      is possible; see `-I'.  The descriptive text can be seen in the
  351.      output from `cvs log' (*note log::.).
  352.  
  353. `-t-STRING'
  354.      Similar to `-tFILE'. Write descriptive text from the STRING into
  355.      the RCS file, deleting the existing text.
  356.  
  357. `-U'
  358.      Set locking to non-strict.  Non-strict locking means that the
  359.      owner of a file need not lock a revision for checkin.  For use
  360.      with CVS, strict locking must be set; see the discussion under the
  361.      `-l' option above.
  362.  
  363. `-u[REV]'
  364.      See the option `-l' above, for a discussion of using this option
  365.      with CVS.  Unlock the revision with number REV.  If a branch is
  366.      given, unlock the latest revision on that branch.  If REV is
  367.      omitted, remove the latest lock held by the caller.  Normally,
  368.      only the locker of a revision may unlock it.  Somebody else
  369.      unlocking a revision breaks the lock.  This causes a mail message
  370.      to be sent to the original locker.  The message contains a
  371.      commentary solicited from the breaker.  The commentary is
  372.      terminated by end-of-file or by a line containing `.' by itself.
  373.  
  374. `-VN'
  375.      Emulate RCS version N. Use -VN to make an RCS file acceptable to
  376.      RCS version N by discarding information that would confuse version
  377.      N.
  378.  
  379. `-xSUFFIXES'
  380.      Useless with CVS. Use SUFFIXES to characterize RCS files.
  381.  
  382. 
  383. File: cvs.info,  Node: admin examples,  Prev: admin options,  Up: admin
  384.  
  385. admin examples
  386. --------------
  387.  
  388. Outdating is dangerous
  389. ......................
  390.  
  391.    First, an example of how *not* to use the `admin' command.  It is
  392. included to stress the fact that this command can be quite dangerous
  393. unless you know *exactly* what you are doing.
  394.  
  395.    The `-o' option can be used to "outdate" old revisions from the
  396. history file.  If you are short on disc this option might help you.
  397. But think twice before using it--there is no way short of restoring the
  398. latest backup to undo this command!
  399.  
  400.    The next line is an example of a command that you would *not* like
  401. to execute.
  402.  
  403.      $ cvs admin -o:R_1_02 .
  404.  
  405.    The above command will delete all revisions up to, and including,
  406. the revision that corresponds to the tag R_1_02.  But beware!  If there
  407. are files that have not changed between R_1_02 and R_1_03 the file will
  408. have *the same* numerical revision number assigned to the tags R_1_02
  409. and R_1_03.  So not only will it be impossible to retrieve R_1_02;
  410. R_1_03 will also have to be restored from the tapes!
  411.  
  412. Comment leaders
  413. ...............
  414.  
  415.    If you use the `$Log$' keyword and you do not agree with the guess
  416. for comment leader that CVS has done, you can enforce your will with
  417. `cvs admin -c'.  This might be suitable for `nroff' source:
  418.  
  419.      $ cvs admin -c'.\" ' *.man
  420.      $ rm *.man
  421.      $ cvs update
  422.  
  423.    The two last steps are to make sure that you get the versions with
  424. correct comment leaders in your working files.
  425.  
  426. 
  427. File: cvs.info,  Node: checkout,  Next: commit,  Prev: admin,  Up: Invoking CVS
  428.  
  429. checkout--Check out sources for editing
  430. =======================================
  431.  
  432.    * Synopsis: checkout [options] modules...
  433.  
  434.    * Requires: repository.
  435.  
  436.    * Changes: working directory.
  437.  
  438.    * Synonyms: co, get
  439.  
  440.    Make a working directory containing copies of the source files
  441. specified by MODULES.  You must execute `checkout' before using most of
  442. the other CVS commands, since most of them operate on your working
  443. directory.
  444.  
  445.    The MODULES part of the command are either symbolic names for some
  446. collection of source directories and files, or paths to directories or
  447. files in the repository.  The symbolic names are defined in the
  448. `modules' file.  *Note modules::.
  449.  
  450.    Depending on the modules you specify, `checkout' may recursively
  451. create directories and populate them with the appropriate source files.
  452. You can then edit these source files at any time (regardless of
  453. whether other software developers are editing their own copies of the
  454. sources); update them to include new changes applied by others to the
  455. source repository; or commit your work as a permanent change to the
  456. source repository.
  457.  
  458.    Note that `checkout' is used to create directories.  The top-level
  459. directory created is always added to the directory where `checkout' is
  460. invoked, and usually has the same name as the specified module.  In the
  461. case of a module alias, the created sub-directory may have a different
  462. name, but you can be sure that it will be a sub-directory, and that
  463. `checkout' will show the relative path leading to each file as it is
  464. extracted into your private work area (unless you specify the `-Q'
  465. global option).
  466.  
  467.    The files created by `checkout' are created read-write, unless the
  468. `-r' option to CVS (*note Global options::.) is specified, the
  469. `CVSREAD' environment variable is specified (*note Environment
  470. variables::.), or a watch is in effect for that file (*note Watches::.).
  471.  
  472.    Running `checkout' on a directory that was already built by a prior
  473. `checkout' is also permitted, and has the same effect as specifying the
  474. `-d' option to the `update' command, that is, any new directories that
  475. have been created in the repository will appear in your work area.
  476. *Note update::.
  477.  
  478.    For the output produced by the `checkout' command see *Note update
  479. output::.
  480.  
  481. * Menu:
  482.  
  483. * checkout options::            checkout options
  484. * checkout examples::           checkout examples
  485.  
  486. 
  487. File: cvs.info,  Node: checkout options,  Next: checkout examples,  Up: checkout
  488.  
  489. checkout options
  490. ----------------
  491.  
  492.    These standard options are supported by `checkout' (*note Common
  493. options::., for a complete description of them):
  494.  
  495. `-D DATE'
  496.      Use the most recent revision no later than DATE.  This option is
  497.      sticky, and implies `-P'.  See *Note Sticky tags::, for more
  498.      information on sticky tags/dates.
  499.  
  500. `-f'
  501.      Only useful with the `-D DATE' or `-r TAG' flags.  If no matching
  502.      revision is found, retrieve the most recent revision (instead of
  503.      ignoring the file).
  504.  
  505. `-k KFLAG'
  506.      Process RCS keywords according to KFLAG.  See co(1).  This option
  507.      is sticky; future updates of this file in this working directory
  508.      will use the same KFLAG.  The `status' command can be viewed to
  509.      see the sticky options.  *Note status::.
  510.  
  511. `-l'
  512.      Local; run only in current working directory.
  513.  
  514. `-n'
  515.      Do not run any checkout program (as specified with the `-o' option
  516.      in the modules file; *note modules::.).
  517.  
  518. `-P'
  519.      Prune empty directories.
  520.  
  521. `-p'
  522.      Pipe files to the standard output.
  523.  
  524. `-r TAG'
  525.      Use revision TAG.  This option is sticky, and implies `-P'.  See
  526.      *Note Sticky tags::, for more information on sticky tags/dates.
  527.  
  528.    In addition to those, you can use these special command options with
  529. `checkout':
  530.  
  531. `-A'
  532.      Reset any sticky tags, dates, or `-k' options.  See *Note Sticky
  533.      tags::, for more information on sticky tags/dates.
  534.  
  535. `-c'
  536.      Copy the module file, sorted, to the standard output, instead of
  537.      creating or modifying any files or directories in your working
  538.      directory.
  539.  
  540. `-d DIR'
  541.      Create a directory called DIR for the working files, instead of
  542.      using the module name.  Unless you also use `-N', the paths
  543.      created under DIR will be as short as possible.
  544.  
  545. `-j TAG'
  546.      With two `-j' options, merge changes from the revision specified
  547.      with the first `-j' option to the revision specified with the
  548.      second `j' option, into the working directory.
  549.  
  550.      With one `-j' option, merge changes from the ancestor revision to
  551.      the revision specified with the `-j' option, into the working
  552.      directory.  The ancestor revision is the common ancestor of the
  553.      revision which the working directory is based on, and the revision
  554.      specified in the `-j' option.
  555.  
  556.      In addition, each -j option can contain an optional date
  557.      specification which, when used with branches, can limit the chosen
  558.      revision to one within a specific date.  An optional date is
  559.      specified by adding a colon (:) to the tag:
  560.      `-jSYMBOLIC_TAG:DATE_SPECIFIER'.
  561.  
  562.      *Note Merging::.
  563.  
  564. `-N'
  565.      Only useful together with `-d DIR'.  With this option, CVS will
  566.      not shorten module paths in your working directory.  (Normally,
  567.      CVS shortens paths as much as possible when you specify an
  568.      explicit target directory).
  569.  
  570. `-s'
  571.      Like `-c', but include the status of all modules, and sort it by
  572.      the status string.  *Note modules::, for info about the `-s'
  573.      option that is used inside the modules file to set the module
  574.      status.
  575.  
  576. 
  577. File: cvs.info,  Node: checkout examples,  Prev: checkout options,  Up: checkout
  578.  
  579. checkout examples
  580. -----------------
  581.  
  582.    Get a copy of the module `tc':
  583.  
  584.      $ cvs checkout tc
  585.  
  586.    Get a copy of the module `tc' as it looked one day ago:
  587.  
  588.      $ cvs checkout -D yesterday tc
  589.  
  590. 
  591. File: cvs.info,  Node: commit,  Next: diff,  Prev: checkout,  Up: Invoking CVS
  592.  
  593. commit--Check files into the repository
  594. =======================================
  595.  
  596.    * Version 1.3 Synopsis: commit [-lnR] [-m 'log_message' | -f file]
  597.      [-r revision] [files...]
  598.  
  599.    * Version 1.3.1 Synopsis: commit [-lnRf] [-m 'log_message' | -F
  600.      file] [-r revision] [files...]
  601.  
  602.    * Requires: working directory, repository.
  603.  
  604.    * Changes: repository.
  605.  
  606.    * Synonym: ci
  607.  
  608.    *Warning:* The `-f FILE' option will probably be renamed to `-F
  609. FILE', and `-f' will be given a new behavior in future releases of CVS.
  610.  
  611.    Use `commit' when you want to incorporate changes from your working
  612. source files into the source repository.
  613.  
  614.    If you don't specify particular files to commit, all of the files in
  615. your working current directory are examined.  `commit' is careful to
  616. change in the repository only those files that you have really changed.
  617. By default (or if you explicitly specify the `-R' option), files in
  618. subdirectories are also examined and committed if they have changed;
  619. you can use the `-l' option to limit `commit' to the current directory
  620. only.
  621.  
  622.    `commit' verifies that the selected files are up to date with the
  623. current revisions in the source repository; it will notify you, and
  624. exit without committing, if any of the specified files must be made
  625. current first with `update' (*note update::.).  `commit' does not call
  626. the `update' command for you, but rather leaves that for you to do when
  627. the time is right.
  628.  
  629.    When all is well, an editor is invoked to allow you to enter a log
  630. message that will be written to one or more logging programs (*note
  631. modules::., and *note loginfo::.) and placed in the RCS history file
  632. inside the repository.  This log message can be retrieved with the
  633. `log' command; *Note log::.  You can specify the log message on the
  634. command line with the `-m MESSAGE' option, and thus avoid the editor
  635. invocation, or use the `-f FILE' option to specify that the argument
  636. file contains the log message.
  637.  
  638. * Menu:
  639.  
  640. * commit options::              commit options
  641. * commit examples::             commit examples
  642.  
  643. 
  644. File: cvs.info,  Node: commit options,  Next: commit examples,  Up: commit
  645.  
  646. commit options
  647. --------------
  648.  
  649.    These standard options are supported by `commit' (*note Common
  650. options::., for a complete description of them):
  651.  
  652. `-l'
  653.      Local; run only in current working directory.
  654.  
  655. `-n'
  656.      Do not run any module program.
  657.  
  658. `-R'
  659.      Commit directories recursively.  This is on by default.
  660.  
  661. `-r REVISION'
  662.      Commit to REVISION.  REVISION must be either a branch, or a
  663.      revision on the main trunk that is higher than any existing
  664.      revision number.  You cannot commit to a specific revision on a
  665.      branch.
  666.  
  667.    `commit' also supports these options:
  668.  
  669. `-F FILE'
  670.      This option is present in CVS releases 1.3-s3 and later.  Read the
  671.      log message from FILE, instead of invoking an editor.
  672.  
  673. `-f'
  674.      This option is present in CVS 1.3-s3 and later releases of CVS.
  675.      Note that this is not the standard behavior of the `-f' option as
  676.      defined in *Note Common options::.
  677.  
  678.      Force CVS to commit a new revision even if you haven't made any
  679.      changes to the file.  If the current revision of FILE is 1.7, then
  680.      the following two commands are equivalent:
  681.  
  682.           $ cvs commit -f FILE
  683.           $ cvs commit -r 1.8 FILE
  684.  
  685. `-f FILE'
  686.      This option is present in CVS releases 1.3, 1.3-s1 and 1.3-s2.
  687.      Note that this is not the standard behavior of the `-f' option as
  688.      defined in *Note Common options::.
  689.  
  690.      Read the log message from FILE, instead of invoking an editor.
  691.  
  692. `-m MESSAGE'
  693.      Use MESSAGE as the log message, instead of invoking an editor.
  694.  
  695. 
  696. File: cvs.info,  Node: commit examples,  Prev: commit options,  Up: commit
  697.  
  698. commit examples
  699. ---------------
  700.  
  701. New major release number
  702. ........................
  703.  
  704.    When you make a major release of your product, you might want the
  705. revision numbers to track your major release number.  You should
  706. normally not care about the revision numbers, but this is a thing that
  707. many people want to do, and it can be done without doing any harm.
  708.  
  709.    To bring all your files up to the RCS revision 3.0 (including those
  710. that haven't changed), you might do:
  711.  
  712.      $ cvs commit -r 3.0
  713.  
  714.    Note that it is generally a bad idea to try to make the RCS revision
  715. number equal to the current release number of your product.  You should
  716. think of the revision number as an internal number that the CVS package
  717. maintains, and that you generally never need to care much about.  Using
  718. the `tag' and `rtag' commands you can give symbolic names to the
  719. releases instead.  *Note tag::, and *Note rtag::.
  720.  
  721.    Note that the number you specify with `-r' must be larger than any
  722. existing revision number.  That is, if revision 3.0 exists, you cannot
  723. `cvs commit -r 1.3'.
  724.  
  725. Committing to a branch
  726. ......................
  727.  
  728.    You can commit to a branch revision (one that has an even number of
  729. dots) with the `-r' option.  To create a branch revision, use the `-b'
  730. option of the `rtag' or `tag' commands (*note tag::.  or *note
  731. rtag::.).  Then, either `checkout' or `update' can be used to base your
  732. sources on the newly created branch.  From that point on, all `commit'
  733. changes made within these working sources will be automatically added
  734. to a branch revision, thereby not disturbing main-line development in
  735. any way.  For example, if you had to create a patch to the 1.2 version
  736. of the product, even though the 2.0 version is already under
  737. development, you might do:
  738.  
  739.      $ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module
  740.      $ cvs checkout -r FCS1_2_Patch product_module
  741.      $ cd product_module
  742.      [[ hack away ]]
  743.      $ cvs commit
  744.  
  745. This works automatically since the `-r' option is sticky.
  746.  
  747. Creating the branch after editing
  748. .................................
  749.  
  750.    Say you have been working on some extremely experimental software,
  751. based on whatever revision you happened to checkout last week.  If
  752. others in your group would like to work on this software with you, but
  753. without disturbing main-line development, you could commit your change
  754. to a new branch.  Others can then checkout your experimental stuff and
  755. utilize the full benefit of CVS conflict resolution.  The scenario might
  756. look like:
  757.  
  758.      [[ hacked sources are present ]]
  759.      $ cvs tag -b EXPR1
  760.      $ cvs update -r EXPR1
  761.      $ cvs commit
  762.  
  763.    The `update' command will make the `-r EXPR1' option sticky on all
  764. files.  Note that your changes to the files will never be removed by the
  765. `update' command.  The `commit' will automatically commit to the
  766. correct branch, because the `-r' is sticky.  You could also do like
  767. this:
  768.  
  769.      [[ hacked sources are present ]]
  770.      $ cvs tag -b EXPR1
  771.      $ cvs commit -r EXPR1
  772.  
  773. but then, only those files that were changed by you will have the `-r
  774. EXPR1' sticky flag.  If you hack away, and commit without specifying
  775. the `-r EXPR1' flag, some files may accidentally end up on the main
  776. trunk.
  777.  
  778.    To work with you on the experimental change, others would simply do
  779.  
  780.      $ cvs checkout -r EXPR1 whatever_module
  781.  
  782. 
  783. File: cvs.info,  Node: diff,  Next: export,  Prev: commit,  Up: Invoking CVS
  784.  
  785. diff--Run diffs between revisions
  786. =================================
  787.  
  788.    * Synopsis: diff [-l] [rcsdiff_options] [[-r rev1 | -D date1] [-r
  789.      rev2 |  -D date2]] [files...]
  790.  
  791.    * Requires: working directory, repository.
  792.  
  793.    * Changes: nothing.
  794.  
  795.    The `diff' command is used to compare different revisions of files.
  796. The default action is to compare your working files with the revisions
  797. they were based on, and report any differences that are found.
  798.  
  799.    If any file names are given, only those files are compared.  If any
  800. directories are given, all files under them will be compared.
  801.  
  802.    The exit status will be 0 if no differences were found, 1 if some
  803. differences were found, and 2 if any error occurred.
  804.  
  805. * Menu:
  806.  
  807. * diff options::                diff options
  808. * diff examples::               diff examples
  809.  
  810. 
  811. File: cvs.info,  Node: diff options,  Next: diff examples,  Up: diff
  812.  
  813. diff options
  814. ------------
  815.  
  816.    These standard options are supported by `diff' (*note Common
  817. options::., for a complete description of them):
  818.  
  819. `-D DATE'
  820.      Use the most recent revision no later than DATE.  See `-r' for how
  821.      this affects the comparison.
  822.  
  823.      CVS can be configured to pass the `-D' option through to `rcsdiff'
  824.      (which in turn passes it on to `diff'.  GNU diff uses `-D' as a
  825.      way to put `cpp'-style `#define' statements around the output
  826.      differences.  There is no way short of testing to figure out how
  827.      CVS was configured.  In the default configuration CVS will use the
  828.      `-D DATE' option.
  829.  
  830. `-k KFLAG'
  831.      Process RCS keywords according to KFLAG.  See co(1).
  832.  
  833. `-l'
  834.      Local; run only in current working directory.
  835.  
  836. `-R'
  837.      Examine directories recursively.  This option is on by default.
  838.  
  839. `-r TAG'
  840.      Compare with revision TAG.  Zero, one or two `-r' options can be
  841.      present.  With no `-r' option, the working file will be compared
  842.      with the revision it was based on.  With one `-r', that revision
  843.      will be compared to your current working file.  With two `-r'
  844.      options those two revisions will be compared (and your working
  845.      file will not affect the outcome in any way).
  846.  
  847.      One or both `-r' options can be replaced by a `-D DATE' option,
  848.      described above.
  849.  
  850.    Any other options that are found are passed through to `rcsdiff',
  851. which in turn passes them to `diff'.  The exact meaning of the options
  852. depends on which `diff' you are using.  The long options introduced in
  853. GNU diff 2.0 are not yet supported in CVS.  See the documentation for
  854. your `diff' to see which options are supported.
  855.  
  856. 
  857. File: cvs.info,  Node: diff examples,  Prev: diff options,  Up: diff
  858.  
  859. diff examples
  860. -------------
  861.  
  862.    The following line produces a Unidiff (`-u' flag) between revision
  863. 1.14 and 1.19 of `backend.c'.  Due to the `-kk' flag no keywords are
  864. substituted, so differences that only depend on keyword substitution
  865. are ignored.
  866.  
  867.      $ cvs diff -kk -u -r 1.14 -r 1.19 backend.c
  868.  
  869.    Suppose the experimental branch EXPR1 was based on a set of files
  870. tagged RELEASE_1_0.  To see what has happened on that branch, the
  871. following can be used:
  872.  
  873.      $ cvs diff -r RELEASE_1_0 -r EXPR1
  874.  
  875.    A command like this can be used to produce a context diff between
  876. two releases:
  877.  
  878.      $ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs
  879.  
  880.    If you are maintaining ChangeLogs, a command like the following just
  881. before you commit your changes may help you write the ChangeLog entry.
  882. All local modifications that have not yet been committed will be
  883. printed.
  884.  
  885.      $ cvs diff -u | less
  886.  
  887. 
  888. File: cvs.info,  Node: export,  Next: history,  Prev: diff,  Up: Invoking CVS
  889.  
  890. export--Export sources from CVS, similar to checkout
  891. ====================================================
  892.  
  893.    * Synopsis: export [-flNn] [-r rev|-D date] [-k subst] [-d dir]
  894.      module...
  895.  
  896.    * Requires: repository.
  897.  
  898.    * Changes: current directory.
  899.  
  900.    This command is a variant of `checkout'; use it when you want a copy
  901. of the source for module without the CVS administrative directories.
  902. For example, you might use `export' to prepare source for shipment
  903. off-site.  This command requires that you specify a date or tag (with
  904. `-D' or `-r'), so that you can count on reproducing the source you ship
  905. to others.
  906.  
  907.    One often would like to use `-kv' with `cvs export'.  This causes
  908. any RCS keywords to be expanded such that an import done at some other
  909. site will not lose the keyword revision information.  But be aware that
  910. doesn't handle an export containing binary files correctly.  Also be
  911. aware that after having used `-kv', one can no longer use the `ident'
  912. command (which is part of the RCS suite--see ident(1)) which looks for
  913. RCS keyword strings.  If you want to be able to use `ident' you must not
  914. use `-kv'.
  915.  
  916. * Menu:
  917.  
  918. * export options::              export options
  919.  
  920. 
  921. File: cvs.info,  Node: export options,  Up: export
  922.  
  923. export options
  924. --------------
  925.  
  926.    These standard options are supported by `export' (*note Common
  927. options::., for a complete description of them):
  928.  
  929. `-D DATE'
  930.      Use the most recent revision no later than DATE.
  931.  
  932. `-f'
  933.      If no matching revision is found, retrieve the most recent
  934.      revision (instead of ignoring the file).
  935.  
  936. `-l'
  937.      Local; run only in current working directory.
  938.  
  939. `-n'
  940.      Do not run any checkout program.
  941.  
  942. `-R'
  943.      Export directories recursively.  This is on by default.
  944.  
  945. `-r TAG'
  946.      Use revision TAG.
  947.  
  948.    In addition, these options (that are common to `checkout' and
  949. `export') are also supported:
  950.  
  951. `-d DIR'
  952.      Create a directory called DIR for the working files, instead of
  953.      using the module name.  Unless you also use `-N', the paths
  954.      created under DIR will be as short as possible.
  955.  
  956. `-k SUBST'
  957.      Set keyword expansion mode (*note Substitution modes::.).
  958.  
  959. `-N'
  960.      Only useful together with `-d DIR'.  With this option, CVS will
  961.      not shorten module paths in your working directory.  (Normally,
  962.      CVS shortens paths as much as possible when you specify an
  963.      explicit target directory.)
  964.  
  965. 
  966. File: cvs.info,  Node: history,  Next: import,  Prev: export,  Up: Invoking CVS
  967.  
  968. history--Show status of files and users
  969. =======================================
  970.  
  971.    * Synopsis:     history [-report] [-flags] [-options args] [files...]
  972.  
  973.    * Requires: the file `$CVSROOT/CVSROOT/history'
  974.  
  975.    * Changes: nothing.
  976.  
  977.    CVS can keep a history file that tracks each use of the `checkout',
  978. `commit', `rtag', `update', and `release' commands.  You can use
  979. `history' to display this information in various formats.
  980.  
  981.    Logging must be enabled by creating the file
  982. `$CVSROOT/CVSROOT/history'.
  983.  
  984.    *Warning:* `history' uses `-f', `-l', `-n', and `-p' in ways that
  985. conflict with the normal use inside CVS (*note Common options::.).
  986.  
  987. * Menu:
  988.  
  989. * history options::             history options
  990.  
  991. 
  992. File: cvs.info,  Node: history options,  Up: history
  993.  
  994. history options
  995. ---------------
  996.  
  997.    Several options (shown above as `-report')  control  what kind of
  998. report is generated:
  999.  
  1000. `-c'
  1001.      Report on each time commit was used (i.e., each time the
  1002.      repository was modified).
  1003.  
  1004. `-e'
  1005.      Everything (all record types); equivalent to specifying
  1006.      `-xMACFROGWUT'.
  1007.  
  1008. `-m MODULE'
  1009.      Report on a particular module.  (You can meaningfully use `-m'
  1010.      more than once on the command line.)
  1011.  
  1012. `-o'
  1013.      Report on checked-out modules.
  1014.  
  1015. `-T'
  1016.      Report on all tags.
  1017.  
  1018. `-x TYPE'
  1019.      Extract a particular set of record types TYPE from the CVS
  1020.      history.  The types are indicated by single letters, which you may
  1021.      specify in combination.
  1022.  
  1023.      Certain commands have a single record type:
  1024.  
  1025.     `F'
  1026.           release
  1027.  
  1028.     `O'
  1029.           checkout
  1030.  
  1031.     `T'
  1032.           rtag
  1033.  
  1034.      One of four record types may result from an update:
  1035.  
  1036.     `C'
  1037.           A merge was necessary but collisions were detected (requiring
  1038.           manual merging).
  1039.  
  1040.     `G'
  1041.           A merge was necessary and it succeeded.
  1042.  
  1043.     `U'
  1044.           A working file was copied from the repository.
  1045.  
  1046.     `W'
  1047.           The working copy of a file was deleted during update (because
  1048.           it was gone from the repository).
  1049.  
  1050.      One of three record types results from commit:
  1051.  
  1052.     `A'
  1053.           A file was added for the first time.
  1054.  
  1055.     `M'
  1056.           A file was modified.
  1057.  
  1058.     `R'
  1059.           A file was removed.
  1060.  
  1061.    The options shown as `-flags' constrain or expand the report without
  1062. requiring option arguments:
  1063.  
  1064. `-a'
  1065.      Show data for all users (the default is to show data only for the
  1066.      user executing `history').
  1067.  
  1068. `-l'
  1069.      Show last modification only.
  1070.  
  1071. `-w'
  1072.      Show only the records for modifications done from the same working
  1073.      directory where `history' is executing.
  1074.  
  1075.    The options shown as `-options ARGS' constrain the report based on
  1076. an argument:
  1077.  
  1078. `-b STR'
  1079.      Show data back to a record containing  the  string STR  in  either
  1080.      the module name, the file name, or the repository path.
  1081.  
  1082. `-D DATE'
  1083.      Show data since DATE.  This is slightly different from the normal
  1084.      use of `-D DATE', which selects the newest revision older than
  1085.      DATE.
  1086.  
  1087. `-p REPOSITORY'
  1088.      Show data for a particular source repository  (you can specify
  1089.      several `-p' options on the same command line).
  1090.  
  1091. `-r REV'
  1092.      Show records referring to revisions since the revision or tag
  1093.      named REV appears in individual RCS files.  Each RCS file is
  1094.      searched for the revision or tag.
  1095.  
  1096. `-t TAG'
  1097.      Show records since tag TAG was last added to the the history file.
  1098.      This differs from the `-r' flag above in that it reads only the
  1099.      history file, not the RCS files, and is much faster.
  1100.  
  1101. `-u NAME'
  1102.      Show records for user NAME.
  1103.  
  1104. 
  1105. File: cvs.info,  Node: import,  Next: log,  Prev: history,  Up: Invoking CVS
  1106.  
  1107. import--Import sources into CVS, using vendor branches
  1108. ======================================================
  1109.  
  1110.    * Synopsis: import [-options] repository vendortag releasetag...
  1111.  
  1112.    * Requires: Repository, source distribution directory.
  1113.  
  1114.    * Changes: repository.
  1115.  
  1116.    Use `import' to incorporate an entire source distribution from an
  1117. outside source (e.g., a source vendor) into your source repository
  1118. directory.  You can use this command both for initial creation of a
  1119. repository, and for wholesale updates to the module from the outside
  1120. source.  *Note Tracking sources::, for a discussion on this subject.
  1121.  
  1122.    The REPOSITORY argument gives a directory name (or a path to a
  1123. directory) under the CVS root directory for repositories; if the
  1124. directory did not exist, import creates it.
  1125.  
  1126.    When you use import for updates to source that has been modified in
  1127. your source repository (since a prior import), it will notify you of
  1128. any files that conflict in the two branches of development; use
  1129. `checkout -j' to reconcile the differences, as import instructs you to
  1130. do.
  1131.  
  1132.    If CVS decides a file should be ignored (*note cvsignore::.), it
  1133. does not import it and prints `I ' followed by the filename (*note
  1134. import output::., for a complete description of the output).
  1135.  
  1136.    If the file `$CVSROOT/CVSROOT/cvswrappers' exists, any file whose
  1137. names match the specifications in that file will be treated as packages
  1138. and the appropriate filtering will be performed on the file/directory
  1139. before being imported, *Note Wrappers::.
  1140.  
  1141.    The outside source is saved in a first-level RCS branch, by default
  1142. 1.1.1.  Updates are leaves of this branch; for example, files from the
  1143. first imported collection of source will be revision 1.1.1.1, then
  1144. files from the first imported update will be revision 1.1.1.2, and so
  1145. on.
  1146.  
  1147.    At least three arguments are required.  REPOSITORY is needed to
  1148. identify the collection of source.  VENDORTAG is a tag for the entire
  1149. branch (e.g., for 1.1.1).  You must also specify at least one
  1150. RELEASETAG to identify the files at the leaves created each time you
  1151. execute `import'.
  1152.  
  1153. * Menu:
  1154.  
  1155. * import options::              import options
  1156. * import output::               import output
  1157. * import examples::             import examples
  1158.  
  1159. 
  1160. File: cvs.info,  Node: import options,  Next: import output,  Up: import
  1161.  
  1162. import options
  1163. --------------
  1164.  
  1165.    This standard option is supported by `import' (*note Common
  1166. options::., for a complete description):
  1167.  
  1168. `-m MESSAGE'
  1169.      Use MESSAGE as log information, instead of invoking an editor.
  1170.  
  1171.    There are three additional special options.
  1172.  
  1173. `-b BRANCH'
  1174.      Specify a first-level branch other than 1.1.1.  Unless the `-b
  1175.      BRANCH' flag is given, revisions will *always* be made to the
  1176.      branch 1.1.1--even if a VENDORTAG that matches another branch is
  1177.      given!  What happens in that case, is that the tag will be reset
  1178.      to 1.1.1.  Warning: This behavior might change in the future.
  1179.  
  1180. `-k SUBST'
  1181.      Indicate the RCS keyword expansion mode desired.  This setting
  1182.      will apply to all files created during the import, but not to any
  1183.      files that previously existed in the repository.  See *Note
  1184.      Substitution modes::, for a list of valid `-k' settings.
  1185.  
  1186. `-I NAME'
  1187.      Specify file names that should be ignored during import.  You can
  1188.      use this option repeatedly.  To avoid ignoring any files at all
  1189.      (even those ignored by default), specify `-I !'.
  1190.  
  1191.      NAME can be a file name pattern of the same type that you can
  1192.      specify in the `.cvsignore' file.  *Note cvsignore::.
  1193.  
  1194. `-W SPEC'
  1195.      Specify file names that should be filtered during import.  You can
  1196.      use this option repeatedly.
  1197.  
  1198.      SPEC can be a file name pattern of the same type that you can
  1199.      specify in the `.cvswrappers' file. *Note Wrappers::.
  1200.  
  1201. 
  1202. File: cvs.info,  Node: import output,  Next: import examples,  Prev: import options,  Up: import
  1203.  
  1204. import output
  1205. -------------
  1206.  
  1207.    `import' keeps you informed of its progress by printing a line for
  1208. each file, preceded by one character indicating the status of the file:
  1209.  
  1210. `U FILE'
  1211.      The file already exists in the repository and has not been locally
  1212.      modified; a new revision has been created (if necessary).
  1213.  
  1214. `N FILE'
  1215.      The file is a new file which has been added to the repository.
  1216.  
  1217. `C FILE'
  1218.      The file already exists in the repository but has been locally
  1219.      modified; you will have to merge the changes.
  1220.  
  1221. `I FILE'
  1222.      The file is being ignored (*note cvsignore::.).
  1223.  
  1224. `L FILE'
  1225.      The file is a symbolic link; at the moment (and for the forseeable
  1226.      future), symbolic links are ignored.  (Various options in the
  1227.      `modules' file can be used to recreate symbolic links on checkout,
  1228.      update, etc.; *note modules::..)
  1229.  
  1230. 
  1231. File: cvs.info,  Node: import examples,  Prev: import output,  Up: import
  1232.  
  1233. import examples
  1234. ---------------
  1235.  
  1236.    *Note Tracking sources::, and *Note From files::.
  1237.  
  1238. 
  1239. File: cvs.info,  Node: log,  Next: rdiff,  Prev: import,  Up: Invoking CVS
  1240.  
  1241. log--Print out log information for files
  1242. ========================================
  1243.  
  1244.    * Synopsis: log [options] [files...]
  1245.  
  1246.    * Requires: repository, working directory.
  1247.  
  1248.    * Changes: nothing.
  1249.  
  1250.    Display log information for files.  `log' used to call the RCS
  1251. utility `rlog'.  Although this is no longer true in the current
  1252. sources, this history determines the format of the output and the
  1253. options, which are not quite in the style of the other CVS commands.
  1254.  
  1255.    The output includes the location of the RCS file, the "head"
  1256. revision (the latest revision on the trunk), all symbolic names (tags)
  1257. and some other things.  For each revision, the revision number, the
  1258. author, the number of lines added/deleted and the log message are
  1259. printed.  All times are displayed in Coordinated Universal Time (UTC).
  1260. (Other parts of CVS print times in the local timezone).
  1261.  
  1262. * Menu:
  1263.  
  1264. * log options::                 log options
  1265. * log examples::                log examples
  1266.  
  1267. 
  1268. File: cvs.info,  Node: log options,  Next: log examples,  Up: log
  1269.  
  1270. log options
  1271. -----------
  1272.  
  1273.    By default, `log' prints all information that is available.  All
  1274. other options restrict the output.
  1275.  
  1276. `-b'
  1277.      Print information about the revisions on the default branch,
  1278.      normally the highest branch on the trunk.
  1279.  
  1280. `-d DATES'
  1281.      Print information about revisions with a checkin date/time in the
  1282.      range given by the semicolon-separated list of dates.  The date
  1283.      formats accepted are those accepted by the `-D' option to many
  1284.      other CVS commands (*note Common options::.).  Dates can be
  1285.      combined into ranges as follows:
  1286.  
  1287.     `D1<D2'
  1288.     `D2>D1'
  1289.           Select the revisions that were deposited between D1 and D2.
  1290.  
  1291.     `<D'
  1292.     `D>'
  1293.           Select all revisions dated D or earlier.
  1294.  
  1295.     `D<'
  1296.     `>D'
  1297.           Select all revisions dated D or later.
  1298.  
  1299.     `D'
  1300.           Select the single, latest revision dated D or earlier.
  1301.  
  1302.      The `>' or `<' characters may be followed by `=' to indicate an
  1303.      inclusive range rather than an exclusive one.
  1304.  
  1305.      Note that the separator is a semicolon (;).
  1306.  
  1307. `-h'
  1308.      Print only the RCS pathname, working pathname, head, default
  1309.      branch, access list, locks, symbolic names, and suffix.
  1310.  
  1311. `-l'
  1312.      Local; run only in current working directory.  (Default is to run
  1313.      recursively).
  1314.  
  1315. `-N'
  1316.      Do not print the list of tags for this file.  This option can be
  1317.      very useful when your site uses a lot of tags, so rather than
  1318.      "more"'ing over 3 pages of tag information, the log information is
  1319.      presented without tags at all.
  1320.  
  1321. `-R'
  1322.      Print only the name of the RCS history file.
  1323.  
  1324. `-rREVISIONS'
  1325.      Print information about revisions given in the comma-separated
  1326.      list REVISIONS of revisions and ranges.  The following table
  1327.      explains the available range formats:
  1328.  
  1329.     `REV1:REV2'
  1330.           Revisions REV1 to REV2 (which must be on the same branch).
  1331.  
  1332.     `:REV'
  1333.           Revisions from the beginning of the branch up to and
  1334.           including REV.
  1335.  
  1336.     `REV:'
  1337.           Revisions starting with REV to the end of the branch
  1338.           containing REV.
  1339.  
  1340.     `BRANCH'
  1341.           An argument that is a branch means all revisions on that
  1342.           branch.
  1343.  
  1344.     `BRANCH1:BRANCH2'
  1345.           A range of branches means all revisions on the branches in
  1346.           that range.
  1347.  
  1348.     `BRANCH.'
  1349.           The latest revision in BRANCH.
  1350.  
  1351.      A bare `-r' with no revisions means the latest revision on the
  1352.      default branch, normally the trunk.  There can be no space between
  1353.      the `-r' option and its argument.
  1354.  
  1355. `-s STATES'
  1356.      Print information about revisions whose state attributes match one
  1357.      of the states given in the comma-separated list STATES.
  1358.  
  1359. `-t'
  1360.      Print the same as `-h', plus the descriptive text.
  1361.  
  1362. `-wLOGINS'
  1363.      Print information about revisions checked in by users with login
  1364.      names appearing in the comma-separated list LOGINS.  If LOGINS is
  1365.      omitted, the user's login is assumed.  There can be no space
  1366.      between the `-w' option and its argument.
  1367.  
  1368.    `log' prints the intersection of the revisions selected with the
  1369. options `-d', `-s', and `-w', intersected with the union of the
  1370. revisions selected by `-b' and `-r'.
  1371.  
  1372. 
  1373. File: cvs.info,  Node: log examples,  Prev: log options,  Up: log
  1374.  
  1375. log examples
  1376. ------------
  1377.  
  1378.    Contributed examples are gratefully accepted.
  1379.  
  1380.