Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
Linux Magazine - Missing Anything?

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Glossary
MoreInfo
Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
FAQ
Copyright Info
Terms of Use
Privacy Info
Disclaimer
WorkBoard
Thanks
Donations
Advertising
Masthead / Impressum
Your Account

Communication
Feedback
Forums
Private Messages
Surveys

Features
HOWTOs
News Archive
Submit News
Topics
User Articles
Web Links

Google
Google


The Web
linux-tutorial.info

Who's Online
There are currently, 149 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

  

cvs



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 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
       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/mod­
              ules,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  `mod­
              ules' file, in either of two formats.  In both cas­
              es, 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­
              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.
              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 `DE­
              FAULT' specifies a command line template to use  if
              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 histo­
              ry').


SEE ALSO

       cvs(1),


COPYING

       Copyright © 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.

  
Show your Support for the Linux Tutorial

Purchase one of the products from our new online shop. For each product you purchase, the Linux Tutorial gets a portion of the proceeds to help keep us going.


Login
Nickname

Password

Security Code
Security Code
Type Security Code


Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!


Amazon Wish List

Did You Know?
The Linux Tutorial welcomes your suggestions and ideas.


Friends



Tell a Friend About Us

Bookmark and Share



Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.06 Seconds