2 First setup

Warning: It might be best to first perform this procedure with an empty test repository, to make sure you understand all consequences. As always, make sure you have recent, readable backups!

2.1 Initializing the repository

The first thing to do when setting up a new repository is to tell CVS to initialize it:

% cvs -d path-to-repository init

This tells CVS to create the CVSROOT administrative directory, where all the customization takes place.

2.2 The repository group

Now we will create the group which will own the repository. All committers need to be in this group, so that they can write to the repository. We will assume the FreeBSD default of ncvs for this group.

# pw groupadd ncvs

Next, you should chown(8) the directory to the group you just added:

# chown -R :ncvs path-to-your-repository

This ensures that no one can write to the repository without proper group permissions.

2.3 Getting the sources

Now you need to obtain the CVSROOT directory from the FreeBSD repository. This is most easily done by checking it out from a FreeBSD anonymous CVS mirror. See the relevant chapter in the handbook for more information. Let us assume that the sources are stored in CVSROOT-freebsd in the current directory.

2.4 Copying the FreeBSD scripts

Next, we will copy the FreeBSD CVSROOT sources into your own repository. If you are accustomed to CVS, you might be thinking that you can just import the scripts, in an attempt to make synchronizing with later versions easier. However, it turns out that CVS has a deficiency in this area: when importing sources into the CVSROOT directory, it will not update the needed administrative files. In order to make it recognize those, you will need to checkin each file after importing them, losing the value of cvs import. Therefore, the recommended method is to simply copy over the scripts.

It does not matter if the above paragraph did not make sense to you—the end result is the same. Simply check out your CVSROOT and copy the FreeBSD files over your local (untouched) copies:

% cvs -d path-to-your-repository checkout CVSROOT
% cd CVSROOT
% cp ../CVSROOT-freebsd/* .
% cvs add *

Note that you will probably get a few warnings about some directories not being copied; this is normal, you do not need those.

2.5 The scripts

Now you have in your working directory an exact copy of the scripts that the FreeBSD project itself uses for their repository. A summary of what each file is used for is included below.

2.6 Customizing the scripts

The next step is to set up the scripts so that they work in your environment. You should go over all files in the directory and make your customizations. In particular, you might want to do edit the following files:

  1. If you do not wish to use the FreeBSD specific features of the scripts, you can safely remove the access file:

    % cvs rm -f access
    
  2. Edit avail to contain the various repository directories in which you want to control access. Make sure you retain the avail||CVSROOT line, otherwise you will lock yourself out in the next step.

    The other thing you can add in this file are committer groups. By default, FreeBSD uses the access file to list all its committers in, but you can use any file you wish. You can also add groups if you want (the syntax is specified at the top of cvs_acls.pl).

  3. Edit cfg_local.pm to contain the options you want. In particular, you should take a look at the following configurable items:

    • %TEMPLATE_HEADERS - these get processed by the log scripts, and inserted below the commit mail if present and non-empty in the commit message. You can probably remove the PR and MFC after entries. And of course you can add your own.

    • $MAIL_BRANCH_HDR - if you want to insert a header into each commit mail describing the branch on which the commit was made, define this to match your setup. Or leave it empty if you do not want such a header.

    • @COMMIT_HOSTS - define this to be a list of hosts on which people can commit.

    • $MAILADDRS - set this to the admin or list address that should receive commit mail.

    • @LOG_FILE_MAP - change this array as you wish - each regexp is matched on the directory of the commit, and the commit log message gets stored in the commitlogs subdirectory in the filename mentioned.

    • $COMMITCHECK_EXTRA - if you do not want to use the FreeBSD specific access checks, you should remove the definition of $COMMITCHECK_EXTRA from this file.

    Note: Changing the $IDHEADER parameter is only guaranteed to work on FreeBSD platforms; it depends on FreeBSD specific modifications to CVS.

    You can check cfg.pm to see which other options can be changed, but the above is a reasonable subset.

  4. Edit exclude to remove the FreeBSD specific entries (such as all lines beginning with ^ports/ etc.). Furthermore, comment out the lines beginning with ^CVSROOT/, and add one line with only ^CVSROOT/ on it. After the wrapper is installed, you can add your header to the files in the CVSROOT directory and restore these lines, but for now they will only be in the way when you try to commit later on.

  5. Edit modules, and delete all FreeBSD stuff. Add your own modules if you wish.

  6. Note: This step is only necessary if you specified a value for $IDHEADER in cfg_local.pm (which only works using a FreeBSD modified CVS).

    Edit options to match the tag you specified in cfg_local.pm. A global search and replace of FreeBSD with your tag should suffice.

  7. Edit rcstemplate to contain the same keywords as specified in cfg_local.pm.

  8. Optionally remove the FreeBSD checks from tagcheck. You can simply add exit 0 to the top of the file to disable all checks on tagging.

  9. The last thing to do before you are finished, is to make sure the commitlogs can be stored. By default these are stored in the repository, in the commitlogs subdirectory of the CVSROOT directory. This directory needs to be created, so do the following:

    % mkdir commitlogs
    % cvs add commitlogs
    

Now, after careful review, you should commit your changes. Be sure that you have granted yourself access to the CVSROOT directory in your avail before you do this, because otherwise you will lock yourself out. So make sure everything is as you intend, and then do the following:

% cvs commit -m '- Initial FreeBSD scripts commit'

2.7 Testing the setup

You are ready for the first test: a forced commit to the avail file, to make sure everything works as expected.

% cvs commit -f -m 'Forced commit to test the new CVSROOT scripts' avail

If everything works, congratulations! You now have a working setup of the FreeBSD scripts for your repository. If CVS still complains about something, go back and recheck if all of the above steps have been performed correctly.