GNU Info

(cvsbook.info)Starting A Repository

---

Next: The Password-Authenticating Server Prev: Anatomy Of A CVS Distribution Up: Repository Administration

---

Enter node , (file) or (file)node

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 Note: 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 Note: 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 Note: 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 Note:
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
(Note: 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.