CVS

CVS is no longer available for new projects, we only offer limited support for CVS for projects previously using it on the Classic SourceForge system.

We recommend that projects upgrade to a more modern SCM, like Subversion, rather than using CVS. CVS has limitations which newer SCM solutions have been designed to overcome. We continue to support CVS for those projects who decide that CVS adequately supports their needs.

Features

SourceForge.net provides the following features in its CVS offering:

  • All standard features of CVS 1.11.x are supported.
  • Developer (read-write) access is provided via CVS over SSH.
  • Anonymous (read-only) access is provided via CVS pserver.
  • A number of CVS clients are supported, including:
    • TortoiseCVS (MS Windows), which can be used in conjunction with PuTTY
    • The official CVS client (Mac OS X, Linux, BSD), which can be used in conjunction with OpenSSH
    • WinCvs (MS Windows), which can be used in conjunction with PuTTY.
  • Repositories may be viewed via web browser via ViewVC.
  • Commit notifications may be made by email using CVS syncmail.
  • Pre-commit and post-commit scripts are supported in several languages.
  • Permissions may be managed as follows:
  • Administrators may manage the repository at a filesystem level using our Interactive shell service.
  • Existing repositories may be imported using our Interactive shell service.
  • Repository backups and mirroring may be performed using rsync.
  • Commit and checkout events are counted in the statistics system.
  • Service usage is not restricted by quotas.

Access

The standard way to modify the contents of your repository is using a CVS client.

CVS admins may also directly modify the repository contents via the interactive shell service. The adminrepo command line tool is used to manage CVS repositories; see adminrepo --help from within a project shell for more information on how to use adminrepo.

Backups

SourceForge.net performs routine backups for all of our servers and will restore from these backups in the event of catastrophic server failure. We encourage projects to make their own backups of CVS data as that data restore can be performed by the project in the event of accidental data destruction by a member of the project team.

Backups of a CVS repository may be made using rsync.

Example (replace PROJECTNAME with the UNIX group name of your project):

rsync -av rsync://a.cvs.sourceforge.net/cvsroot/PROJECTNAME/\* cvs

Conversion

We encourage all CVS projects to convert to svn (which is most similar to cvs) or git (which is more distributed, and has a steeper learning curve). You can convert your repo using one of our interactive shell instances or a host of your own.

For either method, the first step in the conversion is to use the project admin page on sourceforge.net to create an empty repository in the style of your choosing (svn, git, etc.).

If you want to do the conversion on your own machine, start by making a backup copy of your cvs data (so that the conversion isn't bogged down by the remote connection). See the backup instructions above.

If you’d like to instead use an interactive shell for the conversion, request that one be created for you:

 ssh -t USERNAME@shell.sf.net create

When the shell finishes its creation, you will be able to find a read-only version of your cvs repository in the directory /home/cvs/P/PR/PROJECT (where the upper-case letters are taken from your project name). This cvs data is the same replicated copy of your master repo that the pserver hosts use, so if you’ve just committed a change, make sure that you give it a few minutes for the change to make it into the nfs copy.

You will also be able to find your new, empty repository in a directory based on its type, but using a path element of “p” (for project) instead of the P/PR hash directories. For instance, /home/svn/p/PROJECT/code (the “code” directory is typical, but you may have chosen a different name when you created it). If you’re converting on your own machine, checkout the new (empty) repo so that you can populate it and push it back to the server when you’re done.

The interactive shell service provides several conversion tools, including cvs2svn, cvs2git, and git-cvs (used by the “git cvsimport” command).

Converting to Subversion

If you choose to use cvs2svn to convert your repository, you have the choice of converting the entire cvs area or (with the use of a config file) converting a single section of the cvs data at a time (to divide things into several new repos). To convert the whole thing, you can run command similar to this:

cvs2svn --tmpdir ~/cvs2svn-tmp --existing-svnrepos \
  --encoding=utf8 --encoding=latin1 --fallback-encoding=ascii \
  -s /home/svn/p/PROJECT/code /home/cvs/P/PR/PROJECT

Run “cvs2svn --help” for a summary of the available options. The web has more detailed documentation: http://www.mcs.anl.gov/~jacob/cvs2svn/cvs2svn.html

For more intricate conversion options, including converting just a part of the cvs repo into the new repo, you’ll need to create a config file. The documentation above covers that and more.

An interactive shell only stays running for 4 hours, so make sure you have enough time left before you start a big conversion (see the “timeleft” command). Be sure to save any config file you might be editing in your home directory, not in /tmp (so that is saved between shell instances).

Converting to Git

A simple way to convert your repo to git is to use the “git cvsimport” command. For the best conversion result, it helps to create an author.txt mapping file that has the mapping of usernames to the extra user information that git includes. The file should contain lines that look like this:

username = User Name username@users.sourceforge.net

The following command can provide you with a list of all the author usernames:

for vfile in `find /home/cvs/P/PR/PROJECT -name '*,v'`; do
  rlog $vfile | sed -nr 's/^date:.* author: ([^;]+).*/\1/p'
done | sort -u >~/cvs-author-names

Be sure to verify the resulting list -- you’ll probably want to at least remove “root”. You can then turn that list of names into an authors.txt file like this:

for uname in `cat ~/cvs-author-names`; do
  json=`curl https://sourceforge.net/rest/u/$uname/profile`
  fname=`echo "$json" | sed -nr 's/\{"username": "[^"]+", "name": "([^"]+)".*/\1/p'`
  echo "$uname = $fname <$uname@users.sourceforge.net>"
done >~/authors.txt

Be sure to scan the resulting ~/authors.txt file for missing Full Names and make any other changes you want.

Because the cvsimport command wants to create locks inside the read-only cvs dirs, you’ll need to create a copy of your repo for the conversion. If you’re using our interactive shell service you can do a copy like this (note the trailing slashes):

rsync -aiv /home/cvs/P/PR/PROJECT/ ~/cvs/

Also note that the new git dir must not exist yet (you’ll push the result into the project’s “bare” repo later).

So, to do the conversion you can run this:

rm -rf ~/new-git
git cvsimport -v -a -k -d ~/cvs -C ~/new-git -A ~/authors.txt MODULE

The MODULE name is one of your top-level cvs directories. It is very often the same name as the project name.

When that is done you can review the repo’s commits (“git log”), tags (“git tag”), and branches (“git branch -a”) and make any needed tweaks prior to making it public (e.g. removing unneeded tags and/or branches).

When you’re all set, we need to push the resulting git repo to the shared “origin”. Do NOT just copy the new-git dir into your /home/git subdirectory! The “new-git” directory contains a working tree, whilethe directories under /home/git are all “bare” format (without a working tree). To publish the result you can use one of the following “git push” commands.

If you are using our interactive shell service, run this (keep in mind that your PROJECT may have a different mount point than the default "code.git" dir mentioned here):

git push /home/git/p/PROJECT/code.git master
git push /home/git/p/PROJECT/code.git --tags

You can then do a checkout from home of your git repo (see the normal instructions on your project’s git info page) and verify that all is well.

Don’t forget to remove ~/new-git and ~/cvs dirs once you are done with them.

If you are doing a remote conversion, you’ll want to setup the right origin in your new-git dir and then push (note that you typically omit the trailing “.git” from the “code.git” dir):

git remote add origin ssh://USER@git.code.sf.net/p/PROJECT/code
git config branch.master.remote origin
git config branch.master.merge refs/heads/master
git push origin master
git push --tags

That sets up your new git dir to be associated with the remote git repo, just as if you had done a clone. On subsequent pushes you won’t need to specify the “origin master” part of the push, since git will know the association between the remote and local branches.

See also: https://git-scm.com/docs/gitcvs-migration


Related

Documentation: CVS Adminrepo
Documentation: CVS Clients
Documentation: CVS Hook Scripts
Documentation: CVS Permissions
Documentation: CVS Syncmail
Documentation: SSH Key Fingerprints
Documentation: TortoiseCVS
Documentation: WinCvs