The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Интерактивная система просмотра системных руководств (man-ов)

 ТемаНаборКатегория 
 
 [Cписок руководств | Печать]

cvs (5)
  • cvs (1) ( Solaris man: Команды и прикладные программы пользовательского уровня )
  • cvs (1) ( FreeBSD man: Команды и прикладные программы пользовательского уровня )
  • cvs (1) ( Linux man: Команды и прикладные программы пользовательского уровня )
  • >> cvs (5) ( Solaris man: Форматы файлов )
  • cvs (5) ( FreeBSD man: Форматы файлов )
  • cvs (5) ( Linux man: Форматы файлов )
  • Ключ cvs обнаружен в базе ключевых слов.
  • 
    NAME
         cvs - Concurrent Versions System support files
    
    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
         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
              (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 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 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
              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
              expression,  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
              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 tem-
              plate 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.
    
              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 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 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 O 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.
    
    
    
    


    Поиск по тексту MAN-ов: 




    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру