Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
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  collec-
       tions 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 revi-
       sions of	the files to (and modifications	back from) developers' private
       working	directories.   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  ex-
       ist  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, develop-
       ers must	specify	complete path names (absolute, or  relative  to	 $CVS-
       ROOT) for the files they	wish to	manage with cvs	commands.

       You can use the `commitinfo' file to define programs to execute whenev-
       er `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 par-
       ticular 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  al-
       low 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 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  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 collec-
	      tions of source code.  cvs will use these	definitions if you use
	      cvs to check in a	file with the right format  to	`$CVSROOT/CVS-
	      ROOT/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 sym-
	      bolic module name, and the remainder of the line is its  defini-
	      tion.

	      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 work-
	      ing 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  di-
	      rectory  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 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 cre-
	      ate 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 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 argu-
	      ment, 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 ar-
	      gument, 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 argu-
	      ment, 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 remaining arguments  list  the	 files
	      that  are	being modified,	added, or removed by this commit invo-
	      cation.

	      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 tem-
	      plate 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,  fol-
	      lowed  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 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  ex-
	      pression:	 `ALL' specifies a command line	template that must al-
	      ways be executed,	and `DEFAULT' specifies	a  command  line  tem-
	      plate 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 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 regu-
	      lar expression, in this file, contains filenames (of files  con-
	      taining 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 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  ig-
	      nore  during  `cvs update'.  At startup time, cvs	loads the com-
	      piled 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 di-
	      rectories, 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 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 en-
       tire resulting derived work is distributed under	the terms of a permis-
       sion notice identical to	this one.

       Permission is granted to	copy and distribute translations of this manu-
       al into another language, under the above conditions for	modified  ver-
       sions,  except  that this permission notice may be included in transla-
       tions approved by the Free Software Foundation instead of in the	origi-
       nal English.

			       12 February 1992				cvs(5)

NAME | NOTE | SYNOPSIS | DESCRIPTION | FILES | SEE ALSO | COPYING

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=cvs&sektion=5&manpath=FreeBSD+9.3-RELEASE>

home | help