home *** CD-ROM | disk | FTP | other *** search
/ Geek Gadgets 1 / ADE-1.bin / ade-bin / info / cvs.info-1 < prev    next >
Encoding:
GNU Info File  |  1996-10-13  |  49.7 KB  |  1,215 lines
  1. This is Info file cvs.info, produced by Makeinfo-1.64 from the input
  2. file /ade-source/fsf/cvs/doc/cvs.texinfo.
  3.  
  4.    Copyright (C) 1992, 1993 Signum Support AB Copyright (C) 1993, 1994
  5. Free Software Foundation, Inc.
  6.  
  7.    Permission is granted to make and distribute verbatim copies of this
  8. manual provided the copyright notice and this permission notice are
  9. preserved on all copies.
  10.  
  11.    Permission is granted to copy and distribute modified versions of
  12. this manual under the conditions for verbatim copying, provided also
  13. that the section entitled "GNU General Public License" is included
  14. exactly as in the original, and provided that the entire resulting
  15. derived work is distributed under the terms of a permission notice
  16. identical to this one.
  17.  
  18.    Permission is granted to copy and distribute translations of this
  19. manual into another language, under the above conditions for modified
  20. versions, except that the section entitled "GNU General Public License"
  21. and this permission notice may be included in translations approved by
  22. the Free Software Foundation instead of in the original English.
  23.  
  24. 
  25. File: cvs.info,  Node: Top,  Next: Preface,  Up: (dir)
  26.  
  27.  
  28.  
  29.    This info manual describes how to use and administer CVS version
  30. 1.9.
  31.  
  32. * Menu:
  33.  
  34. * Preface::                     About this manual
  35. * What is CVS?::                What is CVS?
  36. * Basic concepts::              Basic concepts of revision management
  37. * A sample session::            A tour of basic CVS usage
  38. * Repository::                  Where all your sources are stored
  39. * Starting a new project::      Starting a project with CVS
  40. * Multiple developers::         How CVS helps a group of developers
  41. * Branches::                    Parallel development explained
  42. * Merging::                     How to move changes between branches
  43. * Recursive behavior::          CVS descends directories
  44. * Adding files::                Adding files
  45. * Removing files::              Removing files
  46. * Tracking sources::            Tracking third-party sources
  47. * Moving files::                Moving and renaming files
  48. * Moving directories::          Moving and renaming directories
  49. * History browsing::            Viewing the history of files in various ways
  50. * Keyword substitution::        CVS can include the revision inside the file
  51. * Binary files::                CVS can handle binary files
  52. * Revision management::         Policy questions for revision management
  53. * Invoking CVS::                Reference manual for CVS commands
  54. * Administrative files::        Reference manual for the Administrative files
  55. * Environment variables::       All environment variables which affect CVS
  56. * Troubleshooting::             Some tips when nothing works
  57. * Copying::                     GNU GENERAL PUBLIC LICENSE
  58. * Index::                       Index
  59.  
  60. 
  61. File: cvs.info,  Node: Preface,  Next: What is CVS?,  Prev: Top,  Up: Top
  62.  
  63. About this manual
  64. *****************
  65.  
  66.    Up to this point, one of the weakest parts of CVS has been the
  67. documentation.  CVS is a complex program.  Previous versions of the
  68. manual were written in the manual page format, which is not really well
  69. suited for such a complex program.
  70.  
  71.    When writing this manual, I had several goals in mind:
  72.  
  73.    * No knowledge of RCS should be necessary.
  74.  
  75.    * No previous knowledge of revision control software should be
  76.      necessary.  All terms, such as "revision numbers", "revision
  77.      trees" and "merging" are explained as they are introduced.
  78.  
  79.    * The manual should concentrate on the things CVS users want to do,
  80.      instead of what the CVS commands can do.  The first part of this
  81.      manual leads you through things you might want to do while doing
  82.      development, and introduces the relevant CVS commands as they are
  83.      needed.
  84.  
  85.    * Information should be easy to find.  In the reference manual in
  86.      the appendices almost all information about every CVS command is
  87.      gathered together.  There is also an extensive index, and a lot of
  88.      cross references.
  89.  
  90.    This manual was contributed by Signum Support AB in Sweden.  Signum
  91. is yet another in the growing list of companies that support free
  92. software.  You are free to copy both this manual and the CVS program.
  93. *Note Copying::, for the details.  Signum Support offers support
  94. contracts and binary distribution for many programs, such as CVS, GNU
  95. Emacs, the GNU C compiler and others.  Write to us for more information.
  96.  
  97.      Signum Support AB
  98.      Box 2044
  99.      S-580 02  Linkoping
  100.      Sweden
  101.      
  102.      Email: info@signum.se
  103.      Phone: +46 (0)13 - 21 46 00
  104.      Fax:   +46 (0)13 - 21 47 00
  105.  
  106.    Another company selling support for CVS is Cyclic Software, web:
  107. `http://www.cyclic.com/', email: `info@cyclic.com'.
  108.  
  109. * Menu:
  110.  
  111. * Checklist::
  112. * Credits::
  113. * BUGS::
  114.  
  115. 
  116. File: cvs.info,  Node: Checklist,  Next: Credits,  Up: Preface
  117.  
  118. Checklist for the impatient reader
  119. ==================================
  120.  
  121.    CVS is a complex system.  You will need to read the manual to be
  122. able to use all of its capabilities.  There are dangers that can easily
  123. be avoided if you know about them, and this manual tries to warn you
  124. about them.  This checklist is intended to help you avoid the dangers
  125. without reading the entire manual.  If you intend to read the entire
  126. manual you can skip this table.
  127.  
  128. Binary files
  129.      CVS can handle binary files, but you must have RCS release 5.5 or
  130.      later and a release of GNU diff that supports the `-a' flag
  131.      (release 1.15 and later are OK).  You must also configure both RCS
  132.      and CVS to handle binary files when you install them.
  133.  
  134.      Keword substitution can be a source of trouble with binary files.
  135.      *Note Keyword substitution::, for solutions.
  136.  
  137. The `admin' command
  138.      Careless use of the `admin' command can cause CVS to cease
  139.      working.  *Note admin::, before trying to use it.
  140.  
  141. 
  142. File: cvs.info,  Node: Credits,  Next: BUGS,  Prev: Checklist,  Up: Preface
  143.  
  144. Credits
  145. =======
  146.  
  147.    Roland Pesch, Cygnus Support <pesch@cygnus.com> wrote the manual
  148. pages which were distributed with CVS 1.3.  Appendix A and B contain
  149. much text that was extracted from them.  He also read an early draft of
  150. this manual and contributed many ideas and corrections.
  151.  
  152.    The mailing-list `info-cvs' is sometimes informative. I have
  153. included information from postings made by the following persons: David
  154. G. Grubbs <dgg@think.com>.
  155.  
  156.    Some text has been extracted from the man pages for RCS.
  157.  
  158.    The CVS FAQ by David G. Grubbs has provided useful material.  The
  159. FAQ is no longer maintained, however, and this manual about the closest
  160. thing there is to a successor (with respect to documenting how to use
  161. CVS, at least).
  162.  
  163.    In addition, the following persons have helped by telling me about
  164. mistakes I've made: Roxanne Brunskill <rbrunski@datap.ca>, Kathy Dyer
  165. <dyer@phoenix.ocf.llnl.gov>, Karl Pingle <pingle@acuson.com>, Thomas A
  166. Peterson <tap@src.honeywell.com>, Inge Wallin <ingwa@signum.se>, Dirk
  167. Koschuetzki <koschuet@fmi.uni-passau.de> and Michael Brown
  168. <brown@wi.extrel.com>.
  169.  
  170. 
  171. File: cvs.info,  Node: BUGS,  Prev: Credits,  Up: Preface
  172.  
  173. BUGS
  174. ====
  175.  
  176.    This manual is known to have room for improvement.  Here is a list
  177. of known deficiencies:
  178.  
  179.    * In the examples, the output from CVS is sometimes displayed,
  180.      sometimes not.
  181.  
  182.    * The input that you are supposed to type in the examples should
  183.      have a different font than the output from the computer.
  184.  
  185.    * This manual should be clearer about what file permissions you
  186.      should set up in the repository, and about setuid/setgid.
  187.  
  188.    * Some of the chapters are not yet complete.  They are noted by
  189.      comments in the `cvs.texinfo' file.
  190.  
  191.    * This list is not complete.  If you notice any error, omission, or
  192.      something that is unclear, please send mail to
  193.      bug-cvs@prep.ai.mit.edu.
  194.  
  195.    I hope that you will find this manual useful, despite the
  196. above-mentioned shortcomings.
  197.  
  198.  
  199.                                                 Linkoping, October 1993
  200.                                                          Per Cederqvist
  201.  
  202. 
  203. File: cvs.info,  Node: What is CVS?,  Next: Basic concepts,  Prev: Preface,  Up: Top
  204.  
  205. What is CVS?
  206. ************
  207.  
  208.    CVS is a version control system.  Using it, you can record the
  209. history of your source files.
  210.  
  211.    For example, bugs sometimes creep in when software is modified, and
  212. you might not detect the bug until a long time after you make the
  213. modification.  With CVS, you can easily retrieve old versions to see
  214. exactly which change caused the bug.  This can sometimes be a big help.
  215.  
  216.    You could of course save every version of every file you have ever
  217. created.  This would however waste an enormous amount of disk space.
  218. CVS stores all the versions of a file in a single file in a clever way
  219. that only stores the differences between versions.
  220.  
  221.    CVS also helps you if you are part of a group of people working on
  222. the same project.  It is all too easy to overwrite each others' changes
  223. unless you are extremely careful.  Some editors, like GNU Emacs, try to
  224. make sure that the same file is never modified by two people at the
  225. same time.  Unfortunately, if someone is using another editor, that
  226. safeguard will not work.  CVS solves this problem by insulating the
  227. different developers from each other.  Every developer works in his own
  228. directory, and CVS merges the work when each developer is done.
  229.  
  230.    CVS started out as a bunch of shell scripts written by Dick Grune,
  231. posted to `comp.sources.unix' in the volume 6 release of December,
  232. 1986.  While no actual code from these shell scripts is present in the
  233. current version of CVS much of the CVS conflict resolution algorithms
  234. come from them.
  235.  
  236.    In April, 1989, Brian Berliner designed and coded CVS.  Jeff Polk
  237. later helped Brian with the design of the CVS module and vendor branch
  238. support.
  239.  
  240.    You can get CVS via anonymous ftp from a number of sites, for
  241. instance prep.ai.mit.edu in `pub/gnu'.
  242.  
  243.    There is a mailing list, known as `info-cvs', devoted to CVS.  To
  244. subscribe or unsubscribe send a message to
  245. `info-cvs-request@prep.ai.mit.edu'.  Please be specific about your
  246. email address.  As of May 1996, subscription requests are handled by a
  247. busy human being, so you cannot expect to be added or removed
  248. immediately.  The usenet group `comp.software.config-mgmt' is also a
  249. suitable place for CVS discussions (along with other configuration
  250. management systems).
  251.  
  252. CVS is not...
  253. =============
  254.  
  255.    CVS can do a lot of things for you, but it does not try to be
  256. everything for everyone.
  257.  
  258. CVS is not a build system.
  259.      Though the structure of your repository and modules file interact
  260.      with your build system (e.g. `Makefile's), they are essentially
  261.      independent.
  262.  
  263.      CVS does not dictate how you build anything.  It merely stores
  264.      files for retrieval in a tree structure you devise.
  265.  
  266.      CVS does not dictate how to use disk space in the checked out
  267.      working directories.  If you write your `Makefile's or scripts in
  268.      every directory so they have to know the relative positions of
  269.      everything else, you wind up requiring the entire repository to be
  270.      checked out.
  271.  
  272.      If you modularize your work, and construct a build system that
  273.      will share files (via links, mounts, `VPATH' in `Makefile's,
  274.      etc.), you can arrange your disk usage however you like.
  275.  
  276.      But you have to remember that *any* such system is a lot of work
  277.      to construct and maintain.  CVS does not address the issues
  278.      involved.
  279.  
  280.      Of course, you should place the tools created to support such a
  281.      build system (scripts, `Makefile's, etc) under CVS.
  282.  
  283.      Figuring out what files need to be rebuilt when something changes
  284.      is, again, something to be handled outside the scope of CVS.  One
  285.      traditional approach is to use `make' for building, and use some
  286.      automated tool for generating the depencies which `make' uses.
  287.  
  288. CVS is not a substitute for management.
  289.      Your managers and project leaders are expected to talk to you
  290.      frequently enough to make certain you are aware of schedules,
  291.      merge points, branch names and release dates.  If they don't, CVS
  292.      can't help.
  293.  
  294.      CVS is an instrument for making sources dance to your tune.  But
  295.      you are the piper and the composer.  No instrument plays itself or
  296.      writes its own music.
  297.  
  298. CVS is not a substitute for developer communication.
  299.      When faced with conflicts within a single file, most developers
  300.      manage to resolve them without too much effort.  But a more
  301.      general definition of "conflict" includes problems too difficult
  302.      to solve without communication between developers.
  303.  
  304.      CVS cannot determine when simultaneous changes within a single
  305.      file, or across a whole collection of files, will logically
  306.      conflict with one another.  Its concept of a "conflict" is purely
  307.      textual, arising when two changes to the same base file are near
  308.      enough to spook the merge (i.e. `diff3') command.
  309.  
  310.      CVS does not claim to help at all in figuring out non-textual or
  311.      distributed conflicts in program logic.
  312.  
  313.      For example: Say you change the arguments to function `X' defined
  314.      in file `A'.  At the same time, someone edits file `B', adding new
  315.      calls to function `X' using the old arguments.  You are outside
  316.      the realm of CVS's competence.
  317.  
  318.      Acquire the habit of reading specs and talking to your peers.
  319.  
  320. CVS does not have change control
  321.      Change control refers to a number of things.  First of all it can
  322.      mean "bug-tracking", that is being able to keep a database of
  323.      reported bugs and the status of each one (is it fixed?  in what
  324.      release?  has the bug submitter agreed that it is fixed?).  For
  325.      interfacing CVS to an external bug-tracking system, see the
  326.      `rcsinfo' and `editinfo' files (*note Administrative files::.).
  327.  
  328.      Another aspect of change control is keeping track of the fact that
  329.      changes to several files were in fact changed together as one
  330.      logical change.  If you check in several files in a single `cvs
  331.      commit' operation, CVS then forgets that those files were checked
  332.      in together, and the fact that they have the same log message is
  333.      the only thing tying them together.  Keeping a GNU style
  334.      `ChangeLog' can help somewhat.
  335.  
  336.      Another aspect of change control, in some systems, is the ability
  337.      to keep track of the status of each change.  Some changes have
  338.      been written by a developer, others have been reviewed by a second
  339.      developer, and so on.  Generally, the way to do this with CVS is to
  340.      generate a diff (using `cvs diff' or `diff') and email it to
  341.      someone who can then apply it using the `patch' utility.  This is
  342.      very flexible, but depends on mechanisms outside CVS to make sure
  343.      nothing falls through the cracks.
  344.  
  345. CVS is not an automated testing program
  346.      It should be possible to enforce mandatory use of a testsuite
  347.      using the `commitinfo' file.  I haven't heard a lot about projects
  348.      trying to do that or whether there are subtle gotchas, however.
  349.  
  350. CVS does not have a builtin process model
  351.      Some systems provide ways to ensure that changes or releases go
  352.      through various steps, with various approvals as needed.
  353.      Generally, one can accomplish this with CVS but it might be a
  354.      little more work.  In some cases you'll want to use the
  355.      `commitinfo', `loginfo', `rcsinfo', or `editinfo' files, to
  356.      require that certain steps be performed before cvs will allow a
  357.      checkin.  Also consider whether features such as branches and tags
  358.      can be used to perform tasks such as doing work in a development
  359.      tree and then merging certain changes over to a stable tree only
  360.      once they have been proven.
  361.  
  362. 
  363. File: cvs.info,  Node: Basic concepts,  Next: A sample session,  Prev: What is CVS?,  Up: Top
  364.  
  365. Basic concepts
  366. **************
  367.  
  368.    CVS stores all files in a centralized "repository" (*note
  369. Repository::.).
  370.  
  371.    The repository contains directories and files, in an arbitrary tree.
  372. The "modules" feature can be used to group together a set of
  373. directories or files into a single entity (*note modules::.).  A
  374. typical usage is to define one module per project.
  375.  
  376. * Menu:
  377.  
  378. * Revision numbers::            The meaning of a revision number
  379. * Versions revisions releases::  Terminology used in this manual
  380.  
  381. 
  382. File: cvs.info,  Node: Revision numbers,  Next: Versions revisions releases,  Up: Basic concepts
  383.  
  384. Revision numbers
  385. ================
  386.  
  387.    Each version of a file has a unique "revision number".  Revision
  388. numbers look like `1.1', `1.2', `1.3.2.2' or even `1.3.2.2.4.5'.  A
  389. revision number always has an even number of period-separated decimal
  390. integers.  By default revision 1.1 is the first revision of a file.
  391. Each successive revision is given a new number by increasing the
  392. rightmost number by one.  The following figure displays a few
  393. revisions, with newer revisions to the right.
  394.  
  395.             +-----+    +-----+    +-----+    +-----+    +-----+
  396.             ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
  397.             +-----+    +-----+    +-----+    +-----+    +-----+
  398.  
  399.    CVS is not limited to linear development.  The "revision tree" can
  400. be split into "branches", where each branch is a self-maintained line of
  401. development.  Changes made on one branch can easily be moved back to
  402. the main trunk.
  403.  
  404.    Each branch has a "branch number", consisting of an odd number of
  405. period-separated decimal integers.  The branch number is created by
  406. appending an integer to the revision number where the corresponding
  407. branch forked off.  Having branch numbers allows more than one branch
  408. to be forked off from a certain revision.
  409.  
  410.    All revisions on a branch have revision numbers formed by appending
  411. an ordinal number to the branch number.  The following figure
  412. illustrates branching with an example.
  413.  
  414.                                                           +-------------+
  415.                                Branch 1.2.2.3.2 ->        ! 1.2.2.3.2.1 !
  416.                                                         / +-------------+
  417.                                                        /
  418.                                                       /
  419.                       +---------+    +---------+    +---------+    +---------+
  420.      Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !----! 1.2.2.4 !
  421.                     / +---------+    +---------+    +---------+    +---------+
  422.                    /
  423.                   /
  424.      +-----+    +-----+    +-----+    +-----+    +-----+
  425.      ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !      <- The main trunk
  426.      +-----+    +-----+    +-----+    +-----+    +-----+
  427.                      !
  428.                      !
  429.                      !   +---------+    +---------+    +---------+
  430.      Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
  431.                          +---------+    +---------+    +---------+
  432.  
  433.    The exact details of how the branch number is constructed is not
  434. something you normally need to be concerned about, but here is how it
  435. works: When CVS creates a branch number it picks the first unused even
  436. integer, starting with 2.  So when you want to create a branch from
  437. revision 6.4 it will be numbered 6.4.2.  All branch numbers ending in a
  438. zero (such as 6.4.0) are used internally by CVS (*note Magic branch
  439. numbers::.).  The branch 1.1.1 has a special meaning.  *Note Tracking
  440. sources::.
  441.  
  442. 
  443. File: cvs.info,  Node: Versions revisions releases,  Prev: Revision numbers,  Up: Basic concepts
  444.  
  445. Versions, revisions and releases
  446. ================================
  447.  
  448.    A file can have several versions, as described above.  Likewise, a
  449. software product can have several versions.  A software product is
  450. often given a version number such as `4.1.1'.
  451.  
  452.    Versions in the first sense are called "revisions" in this document,
  453. and versions in the second sense are called "releases".  To avoid
  454. confusion, the word "version" is almost never used in this document.
  455.  
  456. 
  457. File: cvs.info,  Node: A sample session,  Next: Repository,  Prev: Basic concepts,  Up: Top
  458.  
  459. A sample session
  460. ****************
  461.  
  462.    This section describes a typical work-session using CVS.  It assumes
  463. that a repository is set up (*note Repository::.).
  464.  
  465.    Suppose you are working on a simple compiler.  The source consists
  466. of a handful of C files and a `Makefile'.  The compiler is called `tc'
  467. (Trivial Compiler), and the repository is set up so that there is a
  468. module called `tc'.
  469.  
  470. * Menu:
  471.  
  472. * Getting the source::          Creating a workspace
  473. * Committing your changes::     Making your work available to others
  474. * Cleaning up::                 Cleaning up
  475. * Viewing differences::         Viewing differences
  476.  
  477. 
  478. File: cvs.info,  Node: Getting the source,  Next: Committing your changes,  Up: A sample session
  479.  
  480. Getting the source
  481. ==================
  482.  
  483.    The first thing you must do is to get your own working copy of the
  484. source for `tc'.  For this, you use the `checkout' command:
  485.  
  486.      $ cvs checkout tc
  487.  
  488. This will create a new directory called `tc' and populate it with the
  489. source files.
  490.  
  491.      $ cd tc
  492.      $ ls
  493.      CVS         Makefile    backend.c   driver.c    frontend.c  parser.c
  494.  
  495.    The `CVS' directory is used internally by CVS.  Normally, you should
  496. not modify or remove any of the files in it.
  497.  
  498.    You start your favorite editor, hack away at `backend.c', and a
  499. couple of hours later you have added an optimization pass to the
  500. compiler.  A note to RCS and SCCS users: There is no need to lock the
  501. files that you want to edit.  *Note Multiple developers::, for an
  502. explanation.
  503.  
  504. 
  505. File: cvs.info,  Node: Committing your changes,  Next: Cleaning up,  Prev: Getting the source,  Up: A sample session
  506.  
  507. Committing your changes
  508. =======================
  509.  
  510.    When you have checked that the compiler is still compilable you
  511. decide to make a new version of `backend.c'.
  512.  
  513.      $ cvs commit backend.c
  514.  
  515. CVS starts an editor, to allow you to enter a log message.  You type in
  516. "Added an optimization pass.", save the temporary file, and exit the
  517. editor.
  518.  
  519.    The environment variable `$CVSEDITOR' determines which editor is
  520. started.  If `$CVSEDITOR' is not set, then if the environment variable
  521. `$EDITOR' is set, it will be used. If both `$CVSEDITOR' and `$EDITOR'
  522. are not set then the editor defaults to `vi'.  If you want to avoid the
  523. overhead of starting an editor you can specify the log message on the
  524. command line using the `-m' flag instead, like this:
  525.  
  526.      $ cvs commit -m "Added an optimization pass" backend.c
  527.  
  528. 
  529. File: cvs.info,  Node: Cleaning up,  Next: Viewing differences,  Prev: Committing your changes,  Up: A sample session
  530.  
  531. Cleaning up
  532. ===========
  533.  
  534.    Before you turn to other tasks you decide to remove your working
  535. copy of tc.  One acceptable way to do that is of course
  536.  
  537.      $ cd ..
  538.      $ rm -r tc
  539.  
  540. but a better way is to use the `release' command (*note release::.):
  541.  
  542.      $ cd ..
  543.      $ cvs release -d tc
  544.      M driver.c
  545.      ? tc
  546.      You have [1] altered files in this repository.
  547.      Are you sure you want to release (and delete) module `tc': n
  548.      ** `release' aborted by user choice.
  549.  
  550.    The `release' command checks that all your modifications have been
  551. committed.  If history logging is enabled it also makes a note in the
  552. history file.  *Note history file::.
  553.  
  554.    When you use the `-d' flag with `release', it also removes your
  555. working copy.
  556.  
  557.    In the example above, the `release' command wrote a couple of lines
  558. of output.  `? tc' means that the file `tc' is unknown to CVS.  That is
  559. nothing to worry about: `tc' is the executable compiler, and it should
  560. not be stored in the repository.  *Note cvsignore::, for information
  561. about how to make that warning go away.  *Note release output::, for a
  562. complete explanation of all possible output from `release'.
  563.  
  564.    `M driver.c' is more serious.  It means that the file `driver.c' has
  565. been modified since it was checked out.
  566.  
  567.    The `release' command always finishes by telling you how many
  568. modified files you have in your working copy of the sources, and then
  569. asks you for confirmation before deleting any files or making any note
  570. in the history file.
  571.  
  572.    You decide to play it safe and answer `n RET' when `release' asks
  573. for confirmation.
  574.  
  575. 
  576. File: cvs.info,  Node: Viewing differences,  Prev: Cleaning up,  Up: A sample session
  577.  
  578. Viewing differences
  579. ===================
  580.  
  581.    You do not remember modifying `driver.c', so you want to see what
  582. has happened to that file.
  583.  
  584.      $ cd tc
  585.      $ cvs diff driver.c
  586.  
  587.    This command runs `diff' to compare the version of `driver.c' that
  588. you checked out with your working copy.  When you see the output you
  589. remember that you added a command line option that enabled the
  590. optimization pass.  You check it in, and release the module.
  591.  
  592.      $ cvs commit -m "Added an optimization pass" driver.c
  593.      Checking in driver.c;
  594.      /usr/local/cvsroot/tc/driver.c,v  <--  driver.c
  595.      new revision: 1.2; previous revision: 1.1
  596.      done
  597.      $ cd ..
  598.      $ cvs release -d tc
  599.      ? tc
  600.      You have [0] altered files in this repository.
  601.      Are you sure you want to release (and delete) module `tc': y
  602.  
  603. 
  604. File: cvs.info,  Node: Repository,  Next: Starting a new project,  Prev: A sample session,  Up: Top
  605.  
  606. The Repository
  607. **************
  608.  
  609.    The CVS "repository" stores a complete copy of all the files and
  610. directories which are under version control.
  611.  
  612.    Normally, you never access any of the files in the repository
  613. directly.  Instead, you use CVS commands to get your own copy of the
  614. files, and then work on that copy.  When you've finished a set of
  615. changes, you check (or "commit") them back into the repository.  The
  616. repository then contains the changes which you have made, as well as
  617. recording exactly what you changed, when you changed it, and other such
  618. information.
  619.  
  620.    CVS can access a repository by a variety of means.  It might be on
  621. the local computer, or it might be on a computer across the room or
  622. across the world.  To distinguish various ways to access a repository,
  623. the repository name can start with an "access method".  For example,
  624. the access method `:local:' means to access a repository directory, so
  625. the repository `:local:/usr/local/cvsroot' means that the repository is
  626. in `/usr/local/cvsroot' on the computer running CVS.  For information
  627. on other access methods, see *Note Remote repositories::.
  628.  
  629.    If the access method is omitted, then if the repository does not
  630. contain `:', then `:local:' is assumed.  If it does contain `:' than
  631. either `:ext:' or `:server:' is assumed.  For example, if you have a
  632. local repository in `/usr/local/cvsroot', you can use
  633. `/usr/local/cvsroot' instead of `:local:/usr/local/cvsroot'.  But if
  634. (under Windows NT, for example) your local repository is
  635. `c:\src\cvsroot', then you must specify the access method, as in
  636. `:local:c:\src\cvsroot'.
  637.  
  638.    The repository is split in two parts.  `$CVSROOT/CVSROOT' contains
  639. administrative files for CVS.  The other directories contain the actual
  640. user-defined modules.
  641.  
  642. * Menu:
  643.  
  644. * Specifying a repository::     Telling CVS where your repository is
  645. * Repository storage::          The structure of the repository
  646. * Intro administrative files::  Defining modules
  647. * Multiple repositories::       Multiple repositories
  648. * Creating a repository::       Creating a repository
  649. * Remote repositories::         Accessing repositories on remote machines
  650.  
  651. 
  652. File: cvs.info,  Node: Specifying a repository,  Next: Repository storage,  Up: Repository
  653.  
  654. Telling CVS where your repository is
  655. ====================================
  656.  
  657.    There are a couple of different ways to tell CVS where to find the
  658. repository.  You can name the repository on the command line
  659. explicitly, with the `-d' (for "directory") option:
  660.  
  661.      cvs -d /usr/local/cvsroot checkout yoyodyne/tc
  662.  
  663.    Or you can set the `$CVSROOT' environment variable to an absolute
  664. path to the root of the repository, `/usr/local/cvsroot' in this
  665. example.  To set `$CVSROOT', all `csh' and `tcsh' users should have
  666. this line in their `.cshrc' or `.tcshrc' files:
  667.  
  668.      setenv CVSROOT /usr/local/cvsroot
  669.  
  670. `sh' and `bash' users should instead have these lines in their
  671. `.profile' or `.bashrc':
  672.  
  673.      CVSROOT=/usr/local/cvsroot
  674.      export CVSROOT
  675.  
  676.    A repository specified with `-d' will override the `$CVSROOT'
  677. environment variable.  Once you've checked a working copy out from the
  678. repository, it will remember where its repository is (the information
  679. is recorded in the `CVS/Root' file in the working copy).
  680.  
  681.    The `-d' option and the `CVS/Root' file both override the `$CVSROOT'
  682. environment variable.  If `-d' option differs from `CVS/Root', the
  683. former is used (and specifying `-d' will cause `CVS/Root' to be
  684. updated).  Of course, for proper operation they should be two ways of
  685. referring to the same repository.
  686.  
  687. 
  688. File: cvs.info,  Node: Repository storage,  Next: Intro administrative files,  Prev: Specifying a repository,  Up: Repository
  689.  
  690. How data is stored in the repository
  691. ====================================
  692.  
  693.    For most purposes it isn't important *how* CVS stores information in
  694. the repository.  In fact, the format has changed in the past, and is
  695. likely to change in the future.  Since in almost all cases one accesses
  696. the repository via CVS commands; such changes need not be disruptive.
  697.  
  698.    However, in some cases it may be necessary to understand how CVS
  699. stores data in the repository, for example you might need to track down
  700. CVS locks (*note Concurrency::.) or you might need to deal with the
  701. file permissions appropriate for the repository.
  702.  
  703. * Menu:
  704.  
  705. * Repository files::            What files are stored in the repository
  706. * File permissions::            File permissions
  707.  
  708. 
  709. File: cvs.info,  Node: Repository files,  Next: File permissions,  Up: Repository storage
  710.  
  711. Where files are stored within the repository
  712. --------------------------------------------
  713.  
  714.    The overall structure of the repository is a directory tree
  715. corresponding to the directories in the working directory.  For
  716. example, supposing the repository is in `/usr/local/cvsroot', here is a
  717. possible directory tree (showing only the directories):
  718.  
  719.      /usr
  720.       |
  721.       +--local
  722.       |   |
  723.       |   +--cvsroot
  724.       |   |    |
  725.       |   |    +--CVSROOT
  726.                |      (administrative files)
  727.                |
  728.                +--gnu
  729.                |   |
  730.                |   +--diff
  731.                |   |   (source code to GNU diff)
  732.                |   |
  733.                |   +--rcs
  734.                |   |   (source code to RCS)
  735.                |   |
  736.                |   +--cvs
  737.                |       (source code to CVS)
  738.                |
  739.                +--yoyodyne
  740.                    |
  741.                    +--tc
  742.                    |    |
  743.                    |    +--man
  744.                    |    |
  745.                    |    +--testing
  746.                    |
  747.                    +--(other Yoyodyne software)
  748.  
  749.    With the directories are "history files" for each file under version
  750. control.  The name of the history file is the name of the corresponding
  751. file with `,v' appended to the end.  Here is what the repository for
  752. the `yoyodyne/tc' directory might look like:
  753.  
  754.        `$CVSROOT'
  755.          |
  756.          +--yoyodyne
  757.          |   |
  758.          |   +--tc
  759.          |   |   |
  760.                  +--Makefile,v
  761.                  +--backend.c,v
  762.                  +--driver.c,v
  763.                  +--frontend.c,v
  764.                  +--parser.c,v
  765.                  +--man
  766.                  |    |
  767.                  |    +--tc.1,v
  768.                  |
  769.                  +--testing
  770.                       |
  771.                       +--testpgm.t,v
  772.                       +--test2.t,v
  773.  
  774.    The history files contain, among other things, enough information to
  775. recreate any revision of the file, a log of all commit messages and the
  776. user-name of the person who committed the revision.  The history files
  777. are known as "RCS files", because the first program to store files in
  778. that format was a version control system known as RCS.  For a full
  779. description of the file format, see the `man' page `rcsfile(5)',
  780. distributed with RCS.  This file format has become very common--many
  781. systems other than CVS or RCS can at least import history files in this
  782. format.
  783.  
  784. 
  785. File: cvs.info,  Node: File permissions,  Prev: Repository files,  Up: Repository storage
  786.  
  787. File permissions
  788. ----------------
  789.  
  790.    All `,v' files are created read-only, and you should not change the
  791. permission of those files.  The directories inside the repository
  792. should be writable by the persons that have permission to modify the
  793. files in each directory.  This normally means that you must create a
  794. UNIX group (see group(5)) consisting of the persons that are to edit
  795. the files in a project, and set up the repository so that it is that
  796. group that owns the directory.
  797.  
  798.    This means that you can only control access to files on a
  799. per-directory basis.
  800.  
  801.    Note that users must also have write access to check out files,
  802. because CVS needs to create lock files (*note Concurrency::.).
  803.  
  804.    Also note that users must have write access to the
  805. `CVSROOT/val-tags' file.  CVS uses it to keep track of what tags are
  806. valid tag names (it is sometimes updated when tags are used, as well as
  807. when they are created, though).
  808.  
  809.    CVS tries to set up reasonable file permissions for new directories
  810. that are added inside the tree, but you must fix the permissions
  811. manually when a new directory should have different permissions than its
  812. parent directory.  If you set the `CVSUMASK' environment variable that
  813. will control the file permissions which CVS uses in creating directories
  814. and/or files in the repository.  `CVSUMASK' does not affect the file
  815. permissions in the working directory; such files have the permissions
  816. which are typical for newly created files, except that sometimes CVS
  817. creates them read-only (see the sections on watches, *Note Setting a
  818. watch::; -r, *Note Global options::; or CVSREAD, *Note Environment
  819. variables::).
  820.  
  821.    Since CVS was not written to be run setuid, it is unsafe to try to
  822. run it setuid.  You cannot use the setuid features of RCS together with
  823. CVS.
  824.  
  825. 
  826. File: cvs.info,  Node: Intro administrative files,  Next: Multiple repositories,  Prev: Repository storage,  Up: Repository
  827.  
  828. The administrative files
  829. ========================
  830.  
  831.    The directory `$CVSROOT/CVSROOT' contains some "administrative
  832. files".  *Note Administrative files::, for a complete description.  You
  833. can use CVS without any of these files, but some commands work better
  834. when at least the `modules' file is properly set up.
  835.  
  836.    The most important of these files is the `modules' file.  It defines
  837. all modules in the repository.  This is a sample `modules' file.
  838.  
  839.      CVSROOT         CVSROOT
  840.      modules         CVSROOT modules
  841.      cvs             gnu/cvs
  842.      rcs             gnu/rcs
  843.      diff            gnu/diff
  844.      tc              yoyodyne/tc
  845.  
  846.    The `modules' file is line oriented.  In its simplest form each line
  847. contains the name of the module, whitespace, and the directory where
  848. the module resides.  The directory is a path relative to `$CVSROOT'.
  849. The last four lines in the example above are examples of such lines.
  850.  
  851.    The line that defines the module called `modules' uses features that
  852. are not explained here.  *Note modules::, for a full explanation of all
  853. the available features.
  854.  
  855. Editing administrative files
  856. ----------------------------
  857.  
  858.    You edit the administrative files in the same way that you would edit
  859. any other module.  Use `cvs checkout CVSROOT' to get a working copy,
  860. edit it, and commit your changes in the normal way.
  861.  
  862.    It is possible to commit an erroneous administrative file.  You can
  863. often fix the error and check in a new revision, but sometimes a
  864. particularly bad error in the administrative file makes it impossible
  865. to commit new revisions.
  866.  
  867. 
  868. File: cvs.info,  Node: Multiple repositories,  Next: Creating a repository,  Prev: Intro administrative files,  Up: Repository
  869.  
  870. Multiple repositories
  871. =====================
  872.  
  873.    In some situations it is a good idea to have more than one
  874. repository, for instance if you have two development groups that work
  875. on separate projects without sharing any code.  All you have to do to
  876. have several repositories is to specify the appropriate repository,
  877. using the `CVSROOT' environment variable, the `-d' option to CVS, or
  878. (once you have checked out a working directory) by simply allowing CVS
  879. to use the repository that was used to check out the working directory
  880. (*note Specifying a repository::.).
  881.  
  882.    The big advantage of having multiple repositories is that they can
  883. reside on different servers.  The big disadvantage is that you cannot
  884. have a single CVS command recurse into directories which comes from
  885. different repositories.  Generally speaking, if you are thinking of
  886. setting up several repositories on the same machine, you might want to
  887. consider using several directories within the same repository.
  888.  
  889.    None of the examples in this manual show multiple repositories.
  890.  
  891. 
  892. File: cvs.info,  Node: Creating a repository,  Next: Remote repositories,  Prev: Multiple repositories,  Up: Repository
  893.  
  894. Creating a repository
  895. =====================
  896.  
  897.    To set up a CVS repository, choose a directory with ample disk space
  898. available for the revision history of the source files.  It should be
  899. accessable (directly or via a networked file system) from all machines
  900. which want to use CVS in server or local mode; the client machines need
  901. not have any access to it other than via the CVS protocol.  It is not
  902. possible to use CVS to read from a repository which one only has read
  903. access to; CVS needs to be able to create lock files (*note
  904. Concurrency::.).
  905.  
  906.    To create a repository, run the `cvs init' command.  It will set up
  907. an empty repository in the CVS root specified in the usual way (*note
  908. Repository::.).  For example,
  909.  
  910.      cvs -d /usr/local/cvsroot init
  911.  
  912.    `cvs init' is careful to never overwrite any existing files in the
  913. repository, so no harm is done if you run `cvs init' on an already
  914. set-up repository.
  915.  
  916.    `cvs init' will enable history logging; if you don't want that,
  917. remove the history file after running `cvs init'.  *Note history file::.
  918.  
  919. 
  920. File: cvs.info,  Node: Remote repositories,  Prev: Creating a repository,  Up: Repository
  921.  
  922. Remote repositories
  923. ===================
  924.  
  925.    Your working copy of the sources can be on a different machine than
  926. the repository.  Generally, using a remote repository is just like
  927. using a local one, except that the format of the repository name is:
  928.  
  929.      :METHOD:USER@HOSTNAME:/path/to/repository
  930.  
  931.    The details of exactly what needs to be set up depend on how you are
  932. connecting to the server.
  933.  
  934.    If METHOD is not specified, and the repository name contains `:',
  935. then the default is `ext' or `server', depending on your platform; both
  936. are described in *Note Connecting via rsh::.
  937.  
  938. * Menu:
  939.  
  940. * Connecting via rsh::          Using the `rsh' program to connect
  941. * Password authenticated::      Direct connections using passwords
  942. * Kerberos authenticated::      Direct connections with kerberos
  943.  
  944. 
  945. File: cvs.info,  Node: Connecting via rsh,  Next: Password authenticated,  Up: Remote repositories
  946.  
  947. Connecting with rsh
  948. -------------------
  949.  
  950.    CVS uses the `rsh' protocol to perform these operations, so the
  951. remote user host needs to have a `.rhosts' file which grants access to
  952. the local user.
  953.  
  954.    For example, suppose you are the user `mozart' on the local machine
  955. `anklet.grunge.com', and the server machine is
  956. `chainsaw.brickyard.com'.  On chainsaw, put the following line into the
  957. file `.rhosts' in `bach''s home directory:
  958.  
  959.      anklet.grunge.com  mozart
  960.  
  961.    Then test that `rsh' is working with
  962.  
  963.      rsh -l bach chainsaw.brickyard.com 'echo $PATH'
  964.  
  965.    Next you have to make sure that `rsh' will be able to find the
  966. server.  Make sure that the path which `rsh' printed in the above
  967. example includes the directory containing a program named `cvs' which
  968. is the server.  You need to set the path in `.bashrc', `.cshrc', etc.,
  969. not `.login' or `.profile'.  Alternately, you can set the environment
  970. variable `CVS_SERVER' on the client machine to the filename of the
  971. server you want to use, for example `/usr/local/bin/cvs-1.6'.
  972.  
  973.    There is no need to edit `inetd.conf' or start a CVS server daemon.
  974.  
  975.    There are two access methods that you use in CVSROOT for rsh.
  976. `:server:' specifies an internal rsh client, which is supported only by
  977. some CVS ports.  `:ext:' specifies an external rsh program.  By default
  978. this is `rsh' but you may set the `CVS_RSH' environment variable to
  979. invoke another program which can access the remote server (for example,
  980. `remsh' on HP-UX 9 because `rsh' is something different).  It must be a
  981. program which can transmit data to and from the server without modifying
  982. it; for example the Windows NT `rsh' is not suitable since it by
  983. default translates between CRLF and LF.  The OS/2 CVS port has a hack
  984. to pass `-b' to `rsh' to get around this, but since this could
  985. potentially cause programs for programs other than the standard `rsh',
  986. it may change in the future.  If you set `CVS_RSH' to `SSH' or some
  987. other rsh replacement, the instructions in the rest of this section
  988. concerning `.rhosts' and so on are likely to be incorrect; consult the
  989. documentation for your rsh replacement.
  990.  
  991.    Continuing our example, supposing you want to access the module
  992. `foo' in the repository `/usr/local/cvsroot/', on machine
  993. `chainsaw.brickyard.com', you are ready to go:
  994.  
  995.      cvs -d :ext:bach@chainsaw.brickyard.com:/usr/local/cvsroot checkout foo
  996.  
  997.    (The `bach@' can be omitted if the username is the same on both the
  998. local and remote hosts.)
  999.  
  1000. 
  1001. File: cvs.info,  Node: Password authenticated,  Next: Kerberos authenticated,  Prev: Connecting via rsh,  Up: Remote repositories
  1002.  
  1003. Direct connection with password authentication
  1004. ----------------------------------------------
  1005.  
  1006.    The CVS client can also connect to the server using a password
  1007. protocol.  This is particularly useful if using `rsh' is not feasible
  1008. (for example, the server is behind a firewall), and Kerberos also is
  1009. not available.
  1010.  
  1011.    To use this method, it is necessary to make some adjustments on both
  1012. the server and client sides.
  1013.  
  1014. * Menu:
  1015.  
  1016. * Password authentication server::     Setting up the server
  1017. * Password authentication client::     Using the client
  1018. * Password authentication security::   What this method does and does not do
  1019.  
  1020. 
  1021. File: cvs.info,  Node: Password authentication server,  Next: Password authentication client,  Up: Password authenticated
  1022.  
  1023. Setting up the server for password authentication
  1024. .................................................
  1025.  
  1026.    On the server side, the file `/etc/inetd.conf' needs to be edited so
  1027. `inetd' knows to run the command `cvs pserver' when it receives a
  1028. connection on the right port.  By default, the port number is 2401; it
  1029. would be different if your client were compiled with `CVS_AUTH_PORT'
  1030. defined to something else, though.
  1031.  
  1032.    If your `inetd' allows raw port numbers in `/etc/inetd.conf', then
  1033. the following (all on a single line in `inetd.conf') should be
  1034. sufficient:
  1035.  
  1036.      2401  stream  tcp  nowait  root  /usr/local/bin/cvs
  1037.      cvs -b /usr/local/bin pserver
  1038.  
  1039.    The `-b' option specifies the directory which contains the RCS
  1040. binaries on the server.  You could also use the `-T' option to specify
  1041. a temporary directory.
  1042.  
  1043.    If your `inetd' wants a symbolic service name instead of a raw port
  1044. number, then put this in `/etc/services':
  1045.  
  1046.      cvspserver      2401/tcp
  1047.  
  1048.    and put `cvspserver' instead of `2401' in `inetd.conf'.
  1049.  
  1050.    Once the above is taken care of, restart your `inetd', or do
  1051. whatever is necessary to force it to reread its initialization files.
  1052.  
  1053.    Because the client stores and transmits passwords in cleartext
  1054. (almost--see *Note Password authentication security::, for details), a
  1055. separate CVS password file may be used, so people don't compromise their
  1056. regular passwords when they access the repository.  This file is
  1057. `$CVSROOT/CVSROOT/passwd' (*note Intro administrative files::.).  Its
  1058. format is similar to `/etc/passwd', except that it only has two fields,
  1059. username and password.  For example:
  1060.  
  1061.      bach:ULtgRLXo7NRxs
  1062.      cwang:1sOp854gDF3DY
  1063.  
  1064.    The password is encrypted according to the standard Unix `crypt()'
  1065. function, so it is possible to paste in passwords directly from regular
  1066. Unix `passwd' files.
  1067.  
  1068.    When authenticating a password, the server first checks for the user
  1069. in the CVS `passwd' file.  If it finds the user, it compares against
  1070. that password.  If it does not find the user, or if the CVS `passwd'
  1071. file does not exist, then the server tries to match the password using
  1072. the system's user-lookup routine.  When using the CVS `passwd' file,
  1073. the server runs under as the username specified in the the third
  1074. argument in the entry, or as the first argument if there is no third
  1075. argument (in this way CVS allows imaginary usernames provided the CVS
  1076. `passwd' file indicates corresponding valid system usernames).  In any
  1077. case, CVS will have no privileges which the (valid) user would not have.
  1078.  
  1079.    Right now, the only way to put a password in the CVS `passwd' file
  1080. is to paste it there from somewhere else.  Someday, there may be a `cvs
  1081. passwd' command.
  1082.  
  1083. 
  1084. File: cvs.info,  Node: Password authentication client,  Next: Password authentication security,  Prev: Password authentication server,  Up: Password authenticated
  1085.  
  1086. Using the client with password authentication
  1087. .............................................
  1088.  
  1089.    Before connecting to the server, the client must "log in" with the
  1090. command `cvs login'.  Logging in verifies a password with the server,
  1091. and also records the password for later transactions with the server.
  1092. The `cvs login' command needs to know the username, server hostname,
  1093. and full repository path, and it gets this information from the
  1094. repository argument or the `CVSROOT' environment variable.
  1095.  
  1096.    `cvs login' is interactive -- it prompts for a password:
  1097.  
  1098.      cvs -d :pserver:bach@chainsaw.brickyard.com:/usr/local/cvsroot login
  1099.      CVS password:
  1100.  
  1101.    The password is checked with the server; if it is correct, the
  1102. `login' succeeds, else it fails, complaining that the password was
  1103. incorrect.
  1104.  
  1105.    Once you have logged in, you can force CVS to connect directly to
  1106. the server and authenticate with the stored password:
  1107.  
  1108.      cvs -d :pserver:bach@chainsaw.brickyard.com:/usr/local/cvsroot checkout foo
  1109.  
  1110.    The `:pserver:' is necessary because without it, CVS will assume it
  1111. should use `rsh' to connect with the server (*note Connecting via
  1112. rsh::.).  (Once you have a working copy checked out and are running CVS
  1113. commands from within it, there is no longer any need to specify the
  1114. repository explicitly, because CVS records it in the working copy's
  1115. `CVS' subdirectory.)
  1116.  
  1117.    Passwords are stored by default in the file `$HOME/.cvspass'.  Its
  1118. format is human-readable, but don't edit it unless you know what you
  1119. are doing.  The passwords are not stored in cleartext, but are
  1120. trivially encoded to protect them from "innocent" compromise (i.e.,
  1121. inadvertently being seen by a system administrator who happens to look
  1122. at that file).
  1123.  
  1124.    The `CVS_PASSFILE' environment variable overrides this default.  If
  1125. you use this variable, make sure you set it *before* `cvs login' is
  1126. run.  If you were to set it after running `cvs login', then later CVS
  1127. commands would be unable to look up the password for transmission to
  1128. the server.
  1129.  
  1130.    The `CVS_PASSWORD' environment variable overrides *all* stored
  1131. passwords.  If it is set, CVS will use it for all password-authenticated
  1132. connections.
  1133.  
  1134. 
  1135. File: cvs.info,  Node: Password authentication security,  Prev: Password authentication client,  Up: Password authenticated
  1136.  
  1137. Security considerations with password authentication
  1138. ....................................................
  1139.  
  1140.    The passwords are stored on the client side in a trivial encoding of
  1141. the cleartext, and transmitted in the same encoding.  The encoding is
  1142. done only to prevent inadvertent password compromises (i.e., a system
  1143. administrator accidentally looking at the file), and will not prevent
  1144. even a naive attacker from gaining the password.
  1145.  
  1146.    The separate CVS password file (*note Password authentication
  1147. server::.) allows people to use a different password for repository
  1148. access than for login access.  On the other hand, once a user has
  1149. access to the repository, she can execute programs on the server system
  1150. through a variety of means.  Thus, repository access implies fairly
  1151. broad system access as well.  It might be possible to modify CVS to
  1152. prevent that, but no one has done so as of this writing.  Furthermore,
  1153. there may be other ways in which having access to CVS allows people to
  1154. gain more general access to the system; noone has done a careful audit.
  1155.  
  1156.    In summary, anyone who gets the password gets repository access, and
  1157. some measure of general system access as well.  The password is
  1158. available to anyone who can sniff network packets or read a protected
  1159. (i.e., user read-only) file.  If you want real security, get Kerberos.
  1160.  
  1161. 
  1162. File: cvs.info,  Node: Kerberos authenticated,  Prev: Password authenticated,  Up: Remote repositories
  1163.  
  1164. Direct connection with kerberos
  1165. -------------------------------
  1166.  
  1167.    The main disadvantage of using rsh is that all the data needs to
  1168. pass through additional programs, so it may be slower.  So if you have
  1169. kerberos installed you can connect via a direct TCP connection,
  1170. authenticating with kerberos.
  1171.  
  1172.    To do this, CVS needs to be compiled with kerberos support; when
  1173. configuring CVS it tries to detect whether kerberos is present or you
  1174. can use the `--with-krb4' flag to configure.
  1175.  
  1176.    The data transmitted is *not* encrypted by default.  Encryption
  1177. support must be compiled into both the client and server; use the
  1178. `--enable-encryption' configure option to turn it on.  You must then
  1179. use the `-x' global option to request encryption.
  1180.  
  1181.    You need to edit `inetd.conf' on the server machine to run `cvs
  1182. kserver'.  The client uses port 1999 by default; if you want to use
  1183. another port specify it in the `CVS_CLIENT_PORT' environment variable
  1184. on the client.
  1185.  
  1186.    When you want to use CVS, get a ticket in the usual way (generally
  1187. `kinit'); it must be a ticket which allows you to log into the server
  1188. machine.  Then you are ready to go:
  1189.  
  1190.      cvs -d :kserver:chainsaw.brickyard.com:/user/local/cvsroot checkout foo
  1191.  
  1192.    Previous versions of CVS would fall back to a connection via rsh;
  1193. this version will not do so.
  1194.  
  1195. 
  1196. File: cvs.info,  Node: Starting a new project,  Next: Multiple developers,  Prev: Repository,  Up: Top
  1197.  
  1198. Starting a project with CVS
  1199. ***************************
  1200.  
  1201.    Because renaming files and moving them between directories is
  1202. somewhat inconvenient, the first thing you do when you start a new
  1203. project should be to think through your file organization.  It is not
  1204. impossible to rename or move files, but it does increase the potential
  1205. for confusion and CVS does have some quirks particularly in the area of
  1206. renaming directories.  *Note Moving files::.
  1207.  
  1208.    What to do next depends on the situation at hand.
  1209.  
  1210. * Menu:
  1211.  
  1212. * Setting up the files::        Getting the files into the repository
  1213. * Defining the module::         How to make a module of the files
  1214.  
  1215.