👤
Home Man
Search
Today's Posts
Register

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section of Man Page:
Select Man Page Repository:

RedHat 9 (Linux i386) - man page for cvs (redhat section 5)

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 Man-
       ual) 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  direc-
       tories.	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 individu-
       al source repository is an immediate subdirectory of $CVSROOT.

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

       You  can  use  the `modules' file to define symbolic names for collections of source main-
       tained 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 com-
       mands.

       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  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 reposito-
       ry 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 particular newsgroup.

       You can use the `taginfo' file to define programs to execute after  any	tagorrtag  opera-
       tion.  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 com-
       mitting the change.

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

       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  for-
	      mats.   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 argu-
	      ment) as if the list of names aliases had been specified instead.  aliases may con-
	      tain  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 di-
	      rectory;	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 directory dir.  The sample definition for modules is an exam-
	      ple 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 defi-
	      nition.  checkout creates a subdirectory for each such module, in your working  di-
	      rectory.
	      New  in  cvs  1.3; avoid this feature if sharing module definitions with older ver-
	      sions 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  ver-
	      sions 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 exe-
	      cuted  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
	      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 ar-
	      guments 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 load-
	      ed 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  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' spec-
	      ifies 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  activi-
	      ty,  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 ses-
	      sion; 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 information is recorded.  These "edit" scripts can verify 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 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  up-
	      date'.   At  startup time, cvs loads the compiled in default list of file name pat-
	      terns (see  cvs(1)).   Then  the	per-repository	list  included	in  $CVSROOT/CVS-
	      ROOT/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-direc-
	      tory 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 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  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 lan-
       guage, under the above conditions 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.

					 12 February 1992				   cvs(5)


All times are GMT -4. The time now is 01:26 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
×
UNIX.COM Login
Username:
Password:  
Show Password