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.