Man Pages

cvs(5) - phpMan cvs(5) - phpMan

Command: man perldoc info search(apropos)  


cvs(5)                                                                  cvs(5)



NAME
       cvs - Concurrent Versions System support files

NOTE
       This  documentation  may  no  longer be up to date.  Please consult 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 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 in-
       tended  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 append 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  par-
       ticular 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 messages.

       You can use the 'editinfo' file to define a program to execute for editing/validating 'cvs commit' log entries.
       This is most useful when used with a 'rcsinfo' forms specification, 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 enables 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 comments (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 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 instead.  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 specified 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 single directory called mname  is  created
              as a working directory; no intermediate directory levels are used by default, even if dir was a path in-
              volving several directory levels.

              By explicitly specifying files in the module definition after dir, you can select particular files  from
              directory  dir.   The sample definition for modules is an example 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'
              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  cre-
              ates a subdirectory for each such module, in your working directory.
              New in cvs 1.3; avoid this feature if sharing module 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 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 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 different 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  include
              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 re-
              maining 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
              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  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  mes-
              sage 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 arguments you wish.  The full path to the current log mes-
              sage 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 reg-
              ular 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 exe-
              cute 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.

              The  'editinfo' file allows you to execute a script before the commit starts, but after the log informa-
              tion is recorded.  These "edit" scripts can verify information recorded in the log file.   If  the  edit
              script exits 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 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 patterns) 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/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 di-
              rectory 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 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 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 this permission notice may be included in  translations  approved
       by the Free Software Foundation instead of in the original English.



                               12 February 1992                         cvs(5)