Search:

[Login]  
 Research & Teaching
· Courses

 Resources
· FAQ
· Wiki
· Web Mail
· Mailing Lists
· Web Folders
· Projects

 Search


FAQ (Frequently Asked Questions)

Category: CVS Setup

Questions

Answers

  • How to I set up a CVS repository for use?
    Submitted by: mpotter
    Submitted on: September 9, 2004

    CDS CVS Setup

    Please see the subversion FAQ. CVS is destinend to be decommissioned.

    CDS CVS Setup

    This page describes how to set up CVS repositories for remote access through the CDS CVS pserver. Assume that your CDS username is fred and you want to give access to two collaborators of yours, alice and bob, to two different CVS roots called sysroot and avroot.

    Setting up the CVS roots

    To set up a CVS repository for access through the CDS CVS pserver, do the following steps.
    1. Create the directory cvs_roots in your home directory. This will contain one or more CVS root directories.

    2. Create the new root directories by running the commands:
      cvs -d /home/users/fred/cvs_roots/sysroot init
      cvs -d /home/users/fred/cvs_roots/avroot init
      
      Each time that you add a new root directory, you will have to wait for up to one hour before the system activates it.

    3. Create the file /home/users/fred/cvs_roots/cvs_passwd. Each line in this file will specify a username and password for a remote user of your CVS repositories, as well as listing which roots they should have access to. An example file is:
      alice:qwerty:sysroot,avroot
      bob:asdfg:sysroot
      
      This specifies that the passwords for alice and bob are qwerty and asdfg, respectively. User alice has acess to /home/users/fred/cvs_roots/sysroot and /home/users/fred/cvs_roots/avroot, while bob only has access to /home/users/fred/cvs_roots/sysroot. Note that if a user has access to a root then they automatically have read and write access to all of the modules within that root.

    4. Process the cvs_passwd file to produce the per-root passwd files by running the command:
      cd /home/users/fred/cvs_roots
      cds_process_cvs_passwd
      
      You must rerun this command any time that you make changes to the cvs_passwd file.
    That's it! You will need to wait up to one hour for the system to activate your new CVS roots, but then you will be free to access them remotely using the syntax:
    cvs -d :pserver:alice@cvs.cds.caltech.edu:/home/users/fred/cvs_roots/sysroot cvscommand
    

    Creating modules inside your CVS roots

    Now that you have made one or more CVS roots, you need to create modules within them to hold your projects.

    The easiest way to create a project is to start with some files for the project. For example, assume that you already have a TeX file called fl.tex and you would like to create a module called fl-paper starting with this TeX file, and that this module should go inside the avroot CVS root.

    To do this, put the fl.tex file in a directory all by itself and change into that directory. Then run the command

    cvs -d /home/users/fred/cvs_roots/avroot import -m 'Initial files' fl-paper base start
    
    

    This module will now be available for checkout by authorized users, such as alice, by running the commands

    cvs -d :pserver:alice@cvs.cds.caltech.edu:/home/users/fred/cvs_roots/avroot login
    cvs -d :pserver:alice@cvs.cds.caltech.edu:/home/users/fred/cvs_roots/avroot checkout fl-paper
    

    Access control with cvs_passwd

    Using the above system with multiple CVS roots and multiple modules within each root, there is clearly a lot of choice about whether different projects should be grouped together under one root, given their own roots, or something in between.

    The correct layout of roots and modules will depend on your access control requirements. If a group of people are all collaborating on several projects, then it probably makes sense to group the modules for those projects under a single root and then give everyone in the group access to that root.

    In contrast, if a different group of people work on each project (even if there is overlap), then it is probably best to put each project module in its own root and control access in a very fine grained way. In this case, it is often easiest to keep the module and root names identical.


    Page maintained by: www-cds@cds.caltech.edu

    [Back to Top]