MirOS Manual: cvs(5)


cvs(5)              UNIX Programmer's Manual               cvs(5)

NAME

     cvs - Concurrent Versions System support files

NOTE

     This documentation may no longer be up to date.  Please con-
     sult the Cederqvist (CVS Manual) as specified in cvs(1).

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 hierarchical
     collections  of source directories.  Commands and procedures
     for using cvs are described in cvs(1).

     cvs manages source repositories, the directories  containing
     master  copies  of the revision-controlled files, by copying
     particular revisions of the files to (and modifications back
     from)  developers' private working directories.  In terms of
     file structure, each individual source repository is an  im-
     mediate 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 exe-
     cute  whenever  `cvs commit' is about to execute. These pro-
     grams are used for ``pre-commit'' checking  to  verify  that

MirOS BSD #10-current   12 February 1992                        1

cvs(5)              UNIX Programmer's Manual               cvs(5)

     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 particu-
     lar 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 pro-
     cessed  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 execute
     after  any  commit,  which writes a log entry for changes in
     the repository. These logging programs might be used to  ap-
     pend  the  log  message  to  a file. Or send the log message
     through electronic  mail  to  a  group  of  developers.  Or,
     perhaps, post the log message to a particular newsgroup.

     You can use the `taginfo' file to define programs to execute
     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  particular
     newsgroup.

     You can use the `rcsinfo' file to define forms for log  mes-
     sages.

     You can use the `editinfo' file to define a program to  exe-
     cute  for  editing/validating `cvs commit' log entries. This
     is most useful when used with a `rcsinfo'  forms  specifica-
     tion,  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 de-
          finitions 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 comments

MirOS BSD #10-current   12 February 1992                        2

cvs(5)              UNIX Programmer's Manual               cvs(5)

          (lines  beginning  with  `#') as well as module defini-
          tions. 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  module
          mname. The `-a' flags the definition as a simple alias:
          cvs will treat any use of mname (as a command argument)
          as  if the list of names aliases had been specified in-
          stead.  aliases may contain either other  module  names
          or   paths.   When  you  use  paths  in  aliases,  `cvs
          checkout' creates all intermediate directories  in  the
          working  directory, just as if the path had been speci-
          fied explicitly in the cvs arguments.

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

          In the simplest case, this form  of  module  definition
          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 sin-
          gle  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 definition
          after  dir, you can select particular files from direc-
          tory dir.  The sample definition for modules is an  ex-
          ample  of  a  module  defined with a single file from a
          particular directory.  Here is another example:

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

          With this definition, executing `cvs  checkout  m4test'
          will  create  a  single working directory `m4test' con-
          taining 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  in-
          cluding  `&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  module

MirOS BSD #10-current   12 February 1992                        3

cvs(5)              UNIX Programmer's Manual               cvs(5)

          definitions with older versions of cvs.

          Finally, you can use one or more of the  following  op-
          tions in module definitions:

          `-d name', to name the working directory something oth-
          er than the module name.
          New in cvs 1.3; avoid this feature  if  sharing  module
          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  af-
          fected  directory in a source repository.   The `commi-
          tinfo', `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  different
          points in the `cvs commit' process.  They have a common
          structure. Each line is a pair of fields: a regular ex-
          pression,  separated  by  whitespace from a filename or
          command-line template. Whenever one of the regular  ex-
          pression  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 include not only
          a program name, but  whatever  list  of  arguments  you
          wish.   If  you  write  `%s'  somewhere on the argument

MirOS BSD #10-current   12 February 1992                        4

cvs(5)              UNIX Programmer's Manual               cvs(5)

          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 being modified, added, or removed by
          this commit invocation.

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

          For `commitinfo', 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 arguments you
          wish. The full path to the current 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 tem-
          plate.

          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  arguments  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 tem-
          plate 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  be-
          fore  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  templates
          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 expression, in this file,
          contains filenames (of  files  containing  the  logging
          forms) rather than command templates.

MirOS BSD #10-current   12 February 1992                        5

cvs(5)              UNIX Programmer's Manual               cvs(5)

          The `editinfo' file allows you to execute a script  be-
          fore  the  commit starts, but after the log information
          is recorded.  These "edit" scripts can verify  informa-
          tion  recorded in the log file.  If the edit script ex-
          its with 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 commit log
          message is piped through the command; typical uses  in-
          clude  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 patterns)
          to  ignore  during  `cvs  update'. At startup time, cvs
          loads the compiled in default list of  file  name  pat-
          terns  (see  cvs(1)).  Then the per-repository list in-
          cluded in $CVSROOT/CVSROOT/cvsignore 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 directo-
          ry that contains them, not for any sub-directories.

     history
          Create this file in $CVSROOT/CVSROOT to enable  history
          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 per-
     mission notice are preserved on all copies.

     Permission is granted to copy and distribute  modified  ver-
     sions of this manual under the conditions for verbatim copy-
     ing, provided that the entire resulting derived work is dis-
     tributed 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 condi-
     tions for modified versions, except that this permission no-
     tice  may  be  included in translations approved by the Free
     Software Foundation instead of in the original English.

MirOS BSD #10-current   12 February 1992                        6

Generated on 2014-07-04 21:17:45 by $MirOS: src/scripts/roff2htm,v 1.79 2014/02/10 00:36:11 tg Exp $

These manual pages and other documentation are copyrighted by their respective writers; their source is available at our CVSweb, AnonCVS, and other mirrors. The rest is Copyright © 2002‒2014 The MirOS Project, Germany.
This product includes material provided by Thorsten Glaser.

This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report – diffs preferred.