CVS¶

Importing an existing CVS repository in Tuleap¶

How to properly install a project team’s existing CVS repository into the Tuleap project specific repository

Preamble¶

The main thing to understand about Tuleap is *each* project has its own CVS repository. This root dir is created and initialized by Tuleap whenever a new project is registered. Its name is “/cvsroot/projectname”

I insist on this point because most of the time in many organizations there is one single CVS repository where all projects are stored. The problem with this typical organization is that the directory named “CVSROOT” which contains CVS config and admin files is unique and global to all projects managed by CVS. The directory named “CVSROOT” contains files such as “modules” to declare module name aliases, or commitinfo,rcsinfo and loginfo to trigger specific actions when commit happens (such as e-mail notification to certain people,etc.), or taginfo to put constraints on the TAG formats, or readers and writers which are 2 files to allow/deny access to the CVS repo.

If we had one single CVS repository on Tuleap then the unique and global “CVSROOT” directory would rapidly become a big mess and it would be extremely difficult to maintain all the project specific configurations in this single “CVSROOT” directory. Hence the decision to have one CVS repository per project on Tuleap.

The real work¶

Register the project. Tuleap Admin must approve it and wait for the 30mn cron update to create a fresh /cvsroot/projectname CVS repository with a fresh CVSROOT directory in it. If you are in a hurry you can force the cron update by hand.
Ideally the tar file provided by the team should provide both the CVS top directories *PLUS* the “CVSROOT” directory from the original CVS repository.
Having the CVSROOT in the tarball is not mandatory but if the project had any specific settings in any of the CVS administration file (see above) then there is no chance that the Tuleap admin can rebuilt the same environment on Tuleap. In practice very few projects actually use these admin files but you can’t never know hence the request for the CVSROOT directory to be included in the tarball. One file that is always used though is the CVSROOT/history file where all the actions like commit, add, checkout, etc. are automatically logged by CVS. If the team wants this file to be preserved then again the CVSROOT has to be provided
Create a temporary directory: cd /tmp mkdir projectnamecd projectname
Unpack the cvs tarball provided by the project team in this temporary directory: `` tar xvfz projectname_cvstarball.tgz``

Assuming that the structure is now as follows

/tmp/projectname
   - CVSROOT
       - history  (as well as ,v files)
       - modules
       - commitinfo
       - .....
   - top_level_dir1
   - top_level_dir2
   - ....
   - top_level_dirN

Move all top project dir to the project specific repo: mv top_level_dir* /cvsroot/projectname/ Caution!! Leave the CVSROOT directory in place for the moment
Go to the project CVS repo: cd /cvsroot/projectname
Change the ownership of the entire CVS repo: chown -R projectadminname.projectname top_level_dir* where projectadminname is the Tuleap login of the project administrator
Ensure that setgid bit is properly set on directory: find /cvsroot/projectname -type d -exec chmod g+s {} \;
The CVS admin files in the CVSROOT directory must be examined one by one and the project specific instructions must be merged with the files by the same name in the CVSROOT directory created by Tuleap.
- **Never touch** the CVSROOT/readers, writers, passwd and config files created by Tuleap
- Be careful not to overwrite what is already in the CVSROOT/loginfo and val-tags file. Append the content of these given files at the end of the corresponding ones generated by Tuleap.
- For the history file : extract the lines belonging to the hosted project from the history file provided by the project team (remember it is very likely that this file is global to many projects) and update the content (especially the name of the directories and path listed in the history file if they are not the same on Tuleap)
- For all the other files, look at them one by one and see if there are project specific settings in it. If so append the settings at the end of the corresponding Tuleap files.
Delete the temporary directory: rm -rf /tmp/projectname
Ask the project team to perform a checkout as explained on their CVS project page to check that everything is working fine.

That’s all folks!

Regenerating a fresh CVS or SVN repository for a Tuleap project¶

When the first import goes wrong or the project team screwed up everything and want to start again from scratch

The fastest and safest way (where xxx is the project name):

Log as root
cd /cvsroot for a CVS repository, or cd /svnroot for a SVN repository
Make a backup copy of the current tree in /tmp just in case…: tar cvfz /tmp/xxx_repository.tgz ./xxx
Delete the CVS or SVN tree: rm -rf xxx
Wait for the SYSTEM_CHECK system event to run.
Delete corresponding entries from cvs_checkins, cvs_commits and cvs_descs tables to prevent showing them while browsing commits with viewVC.

Now you have a fresh CVS or SVN repository and the team can start the import again.

Convert a CVS repository to Subversion¶

Some projects may want to switch from CVS to Subversion. There are many good reasons for this, e.g. performance increase over CVS as well as many new features like directory and symbolic link versioning, file and directory move, truly atomic commits, etc.

Unfortunately, project members cannot do the full conversion process by themselves because of permission issues.

Here are the step-by-step instructions:

Log in as root.
If not already done, install cvs2svn from http://cvs2svn.tigris.org
Check that the SVN repository is empty:
```
svnlook info /svnroot/projname
```
Then simply type:
```
cvs2svn --existing-svnrepos -s /svnroot/projname --tmpdir=/tmp /cvsroot/projname
```
You might need to add “–encoding=iso8859-1 –encoding=utf_8” if the conversion process stops because of character encoding issues. Note: If the conversion fails with a Berkeley DB error, this might be caused by BDB version differences between the svn client (v1.2+) and the svn repository (v1.0 or v1.1). In this case, delete the old repository, and recreate it with the backend script. Actually, you should also upgrade all existing svn repositories that use the deprecated version of BDB…
This will convert the CVS repository with all the historical information (including all commits, tags and branches). To select a set of historical data, please read: http://cvs2svn.tigris.org/cvs2svn.html
You should then set proper ownership on the repository:
```
chown -R codendiadm.projname /svnroot/projname
```
Activate the Subversion service in Tuleap if it is disabled.
You may also populate the Tuleap DB with subversion revision details: you need to execute as codendiadm ‘/usr/lib/tuleap/bin/commit-email.pl NNN’ for each revision number (NNN) created. Please note however that CVS commits performed by people whose login name does not correspond to Tuleap logins won’t appear.