Starting A Repository

Once the CVS executable is installed on your system, you can start using it right away as a client to access remote repositories, following the procedures described in An Overview of CVS. However, if you want to serve revisions from your machine, you have to create a repository there. The command to do that is

     floss$ cvs -d /usr/local/newrepos init

where /usr/local/newrepos is a path to wherever you want the repository to be (of course, you must have write permission to that location, which may imply running the command as the root user). It may seem somewhat counterintuitive that the location of the new repository is specified before the init subcommand instead of after it, but by using the -d option, it stays consistent with other CVS commands.

The command will return silently after it is run. Let's examine the new directory:

     floss$ ls -ld /usr/local/newrepos
     drwxrwxr-x   3 root     root         1024 Jun 19 17:59 /usr/local/newrepos/
     floss$ cd /usr/local/newrepos
     floss$ ls
     CVSROOT
     floss$ cd CVSROOT
     floss$ ls
     checkoutlist     config,v        history     notify     taginfo,v
     checkoutlist,v   cvswrappers     loginfo     notify,v   verifymsg
     commitinfo       cvswrappers,v   loginfo,v   rcsinfo    verifymsg,v
     commitinfo,v     editinfo        modules     rcsinfo,v
     config           editinfo,v      modules,v   taginfo
     
     floss$

The single subdirectory in the new repository – CVSROOT/ – contains various administrative files that control CVS's behavior. Later on, we'll examine those files one by one; for now, the goal is just to get the repository working. In this case, "working" means users can import, check out, update, and commit projects.

Don't confuse the CVSROOT environment variable introduced in An Overview of CVS with this CVSROOT subdirectory in the repository. They are unrelated – it is an unfortunate coincidence that they share the same name. The former is a way for users to avoid having to type `-d <repository-location>' every time they use CVS; the latter is the administrative subdirectory of a repository.

Once the repository is created, you must take care of its permissions. CVS does not require any particular, standardized permission or file ownership scheme; it merely needs write access to the repository. However – partly for security reasons, but mainly for your own sanity as an administrator – I highly recommend that you take the following steps:

1. Add a Unix group cvs to your system. Any users who need to access the repository should be in this group. For example, here's the relevant line from my machine's /etc/group file:

             cvs:*:105:kfogel,sussman,jimb,noel,lefty,fitz,craig,anonymous,jrandom
        

2. Make the repository's group ownership and permissions reflect this new group:

             floss$ cd /usr/local/newrepos
             floss$ chgrp -R cvs .
             floss$ chmod ug+rwx . CVSROOT
        

Now any of the users listed in that group can start a project by running cvs import, as described in An Overview of CVS. Checkout, update, and commit should work as well. They can also reach the repository from remote locations by using the :ext: method, assuming that they have rsh or ssh access to the repository machine. (You may have noticed that the chgrp and chmod commands in that example gave write access to a user named anonymous, which is not what one would expect. The reason is that even anonymous, read-only repository users need system-level write access, so that their CVS processes can create temporary lockfiles inside the repository. CVS enforces the "read-only" restriction of anonymous access not through Unix file permissions, but by other means, which will be covered in Anonymous Access.)

If your repository is intended to serve projects to the general public, where contributors won't necessarily have accounts on the repository machine, you should set up the password-authenticating server now (see The Password-Authenticating Server). It's necessary for anonymous read-only access, and it's also probably the easiest way to grant commit access to certain people without giving them full accounts on the machine.