cvs(5)                                                     cvs(5)

NAME
       cvs - Concurrent Versions System support files

SYNOPSIS
       $CVSROOT/CVSROOT/commitinfo,v

       $CVSROOT/CVSROOT/cvsignore,v

       $CVSROOT/CVSROOT/cvswrappers,v

       $CVSROOT/CVSROOT/editinfo,v

       $CVSROOT/CVSROOT/history

       $CVSROOT/CVSROOT/loginfo,v

       $CVSROOT/CVSROOT/modules,v

       $CVSROOT/CVSROOT/rcsinfo,v

       $CVSROOT/CVSROOT/taginfo,v

DESCRIPTION
       cvs is a system for providing source control to hierarchi-
       cal collections of source directories.  Commands and  pro-
       cedures for using cvs are described in cvs(1).

       cvs  manages source repositories, the directories contain-
       ing master copies of  the  revision-controlled  files,  by
       copying  particular revisions of the files to (and modifi-
       cations back from) developers'  private  working  directo-
       ries.   In terms of file structure, each individual source
       repository is an immediate subdirectory of $CVSROOT.

       The files described here are supporting files; they do not
       have  to  exist  for cvs to operate, but they allow you to
       make cvs operation more flexible.

       You can use the `modules' file to  define  symbolic  names
       for  collections  of source maintained with cvs.  If there
       is no `modules' file,  developers  must  specify  complete
       path  names  (absolute,  or  relative to $CVSROOT) for the
       files they wish to manage with cvs commands.

       You can use the `commitinfo' file to  define  programs  to
       execute  whenever `cvs commit' is about to execute.  These
       programs are used for ``pre-commit''  checking  to  verify
       that  the  modified,  added,  and removed files are really
       ready to be committed.  Some uses for this check might  be
       to  turn  off  a portion (or all) of the source repository
       from a particular person or group.  Or, perhaps, to verify
       that the changed files conform to the site's standards for
       coding practice.

       You can use the `cvswrappers' file to record  cvs  wrapper
       commands  to  be  used when checking files into and out of
       the repository.  Wrappers allow the file or  directory  to
       be  processed  on the way in and out of CVS.  The intended
       uses are many, one possible use would be to reformat  a  C
       file  before the file is checked in, so all of the code in
       the repository looks the same.

       You can use the `loginfo' file to define programs to  exe-
       cute  after  any  commit,  which  writes  a  log entry for
       changes in the repository.  These logging  programs  might
       be  used to append the log message to a file.  Or send the
       log message through electronic mail to a group of develop-
       ers.   Or,  perhaps,  post the log message to a particular
       newsgroup.

       You can use the `taginfo' file to define programs to  exe-
       cute  after any tagorrtag operation.  These programs might
       be used to append a message to a file listing the new  tag
       name  and the programmer who created it, or send mail to a
       group of developers, or, perhaps, post a message to a par-
       ticular newsgroup.

       You  can  use  the  `rcsinfo' file to define forms for log
       messages.

       You can use the `editinfo' file to define a program to ex-
       ecute  for  editing/validating  `cvs  commit' log entries.
       This is most useful when used with a `rcsinfo' forms spec-
       ification,  as it can verify that the proper fields of the
       form have been  filled  in  by  the  user  committing  the
       change.

       You  can  use  the `cvsignore' file to specify the default
       list of files to ignore during update.

       You can use the `history' file to record the cvs  commands
       that affect the repository.  The creation of this file en-
       ables history logging.

FILES
       modules
              The `modules'  file  records  your  definitions  of
              names for collections of source code.  cvs will use
              these definitions if you use cvs to check in a file
              with        the        right        format       to
              `$CVSROOT/CVSROOT/modules,v'.

              The `modules' file may contain blank lines and com-
              ments  (lines beginning with `#') as well as module
              definitions.  Long lines can be  continued  on  the
              next  line by specifying a backslash (``\'') as the
              last character on the line.

              A  module  definition  is  a  single  line  of  the
              `modules'  file, in either of two formats.  In both
              cases, mname represents the symbolic  module  name,
              and the remainder of the line is its definition.

              mname -a aliases...
              This represents the simplest way of defining a mod-
              ule mname.  The `-a' flags the definition as a sim-
              ple  alias:  cvs  will treat any use of mname (as a
              command argument) as if the list of  names  aliases
              had  been  specified  instead.  aliases may contain
              either other module names or paths.  When  you  use
              paths in aliases, `cvs checkout' creates all inter-
              mediate directories in the working directory,  just
              as if the path had been specified explicitly in the
              cvs arguments.

              mname [ options ] dir [ files... ] [ &module... ]

              In the simplest case, this form of  module  defini-
              tion  reduces to `mname dir'.  This defines all the
              files in directory dir as module mname.  dir  is  a
              relative  path  (from  $CVSROOT)  to a directory of
              source in one of the source repositories.  In  this
              case,  on checkout, a single directory called mname
              is created as a working directory; no  intermediate
              directory  levels  are used by default, even if dir
              was a path involving several directory levels.

              By explicitly specifying files in the module  defi-
              nition  after  dir, you can select particular files
              from directory dir.  The sample definition for mod-
              ules  is an example of a module defined with a sin-
              gle file from a particular directory.  Here is  an-
              other example:

              m4test  unsupported/gnu/m4 foreach.m4 forloop.m4

              With   this  definition,  executing  `cvs  checkout
              m4test' will  create  a  single  working  directory
              `m4test'  containing  the  two  files listed, which
              both come from a common  directory  several  levels
              deep in the cvs source repository.

              A  module  definition can refer to other modules by
              including `&module' in  its  definition.   checkout
              creates  a  subdirectory  for  each such module, in
              your working directory.
              New in cvs 1.3; avoid this feature if sharing  mod-
              ule definitions with older versions of cvs.

              Finally,  you  can use one or more of the following
              options in module definitions:

              `-d name', to name the working directory  something
              other than the module name.
              New  in cvs 1.3; avoid this feature if sharing mod-
              ule definitions with older versions of cvs.

              `-i prog' allows you to specify a program  prog  to
              run whenever files in a module are committed.  prog
              runs with a single argument, the full  pathname  of
              the  affected  directory  in  a  source repository.
              The `commitinfo', `loginfo', and  `editinfo'  files
              provide other ways to call a program on commit.

              `-o  prog'  allows you to specify a program prog to
              run whenever files in a  module  are  checked  out.
              prog  runs with a single argument, the module name.

              `-e prog' allows you to specify a program  prog  to
              run  whenever files in a module are exported.  prog
              runs with a single argument, the module name.

              `-t prog' allows you to specify a program  prog  to
              run  whenever  files  in a module are tagged.  prog
              runs with two arguments:  the module name  and  the
              symbolic tag specified to rtag.

              `-u  prog'  allows you to specify a program prog to
              run whenever `cvs update' is executed from the top-
              level  directory  of  the checked-out module.  prog
              runs with a single argument, the full path  to  the
              source repository for this module.

       commitinfo, loginfo, rcsinfo, editinfo
              These files all specify programs to call at differ-
              ent points in the `cvs commit' process.  They  have
              a common structure.  Each line is a pair of fields:
              a regular expression, separated by whitespace  from
              a  filename or command-line template.  Whenever one
              of the regular expression matches a directory  name
              in  the  repository,  the rest of the line is used.
              If the line begins with a # character,  the  entire
              line  is  considered  a  comment  and  is  ignored.
              Whitespace between the fields is also ignored.

              For `loginfo', the rest of the line is  a  command-
              line  template  to  execute.  The templates can in-
              clude not only a program name, but whatever list of
              arguments you wish.  If you write `%s' somewhere on
              the argument list, cvs supplies, at that point, the
              list  of  files  affected by the commit.  The first
              entry in the list is the relative path  within  the
              source  repository  where the change is being made.
              The remaining arguments list the files that are be-
              ing  modified, added, or removed by this commit in-
              vocation.

              For `taginfo', the rest of the line is  a  command-
              line  template to execute.  The arguments passed to
              the command are, in order, the tagname ,  operation
              (i.e.  add for `tag', mov for `tag -F', and del for
              `tag -d`), repository , and any remaining are pairs
              of filename revision .  A non-zero exit of the fil-
              ter program will cause the tag to be aborted.

              For `commitinfo', the rest of the line  is  a  com-
              mand-line  template  to  execute.  The template can
              include not only a program name, but whatever  list
              of  arguments  you wish.  The full path to the cur-
              rent source repository is appended to the template,
              followed by the file names of any files involved in
              the commit (added, removed, and modified files).

              For `rcsinfo', the rest of the  line  is  the  full
              path  to  a file that should be loaded into the log
              message template.

              For `editinfo', the rest of the line is a  command-
              line template to execute.  The template can include
              not only a program name, but whatever list of argu-
              ments  you  wish.  The full path to the current log
              message template file is appended to the  template.

              You can use one of two special strings instead of a
              regular expression: `ALL' specifies a command  line
              template   that   must   always  be  executed,  and
              `DEFAULT' specifies a command line template to  use
              if no regular expression is a match.

              The  `commitinfo' file contains commands to execute
              before any other commit activity, to allow  you  to
              check  any conditions that must be satisfied before
              commit can proceed.  The rest of  the  commit  will
              execute  only  if  all  selected commands from this
              file exit with exit status 0.

              The `rcsinfo' file allows you to specify  log  tem-
              plates  for the commit logging session; you can use
              this to provide a form to edit when filling out the
              commit  log.   The  field after the regular expres-
              sion, in this file, contains  filenames  (of  files
              containing  the  logging forms) rather than command
              templates.

              The `editinfo' file allows you to execute a  script
              before  the commit starts, but after the log infor-
              mation is recorded.  These "edit" scripts can veri-
              fy  information  recorded  in the log file.  If the
              edit script exits wth a non-zero exit  status,  the
              commit is aborted.

              The  `loginfo' file contains commands to execute at
              the end of a commit.  The text specified as a  com-
              mit log message is piped through the command; typi-
              cal uses include sending mail, filing an article in
              a newsgroup, or appending to a central file.

       cvsignore, .cvsignore
              The  default list of files (or sh(1) file name pat-
              terns) to ignore during `cvs update'.   At  startup
              time,  cvs  loads  the  compiled in default list of
              file name patterns (see  cvs(1)).   Then  the  per-
              repository list included in $CVSROOT/CVSROOT/cvsig-
              nore is loaded, if it exists.   Then  the  per-user
              list  is  loaded from `$HOME/.cvsignore'.  Finally,
              as cvs traverses through your directories, it  will
              load  any per-directory `.cvsignore' files whenever
              it finds one.  These per-directory files  are  only
              valid for exactly the directory that contains them,
              not for any sub-directories.

       history
              Create this file in $CVSROOT/CVSROOT to enable his-
              tory   logging   (see   the   description  of  `cvs
              history').

SEE ALSO
       cvs(1),

COPYING
       Copyright (C) 1992 Cygnus  Support,  Brian  Berliner,  and
       Jeff Polk

       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 ver-
       sions of this manual under  the  conditions  for  verbatim
       copying,  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 con-
       ditions for modified versions, except that this permission
       notice may be included in  translations  approved  by  the
       Free  Software  Foundation  instead of in the original En-
       glish.

                         12 February 1992                       1