Contents

• Contents
• Steps for converting your CVS repository to Subversion at the ASF
• A sample repository conversion request
• Performing a migration

1. Your project's PMC has to decide that it's ready to convert to Subversion.
2. Decide how you want your repository converted. Read the cvs2svn manual for the different ways in which you can convert your CVS repository. You should then come up with a set of conversion instructions like this.
3. A member of your PMC should mail the request, along with the manner in which you'd like your repository converted with the text "Convert $PROJECT to Subversion" in the subject to infrastructure@apache.org, cc'ing the PMC. You should also file an issue tracker request under the Subversion component in the infrastructure project with this same information.
4. Someone from the infrastructure team will accept your issue, possibly asking for more information. The infrastructure team may have some recommendation about alterations. Keep in mind that the infrastructure team is swamped, but don't let us drop the ball: weekly reminders should eventually be sufficient.
5. Once all the necessary information is received, the infrastructure team will ask to schedule a time to do the conversion. To minimize the number of round trips (and to ensure the conversion doesn't get dropped), the test load and the real load will happen together. All interested participants from the project should be invited at that time to examine the test load and provide feedback in real-time before the real load commences.
6. Your CVS repository will be locked down (converted to read-only). The PMC will be responsible for notifying the participants that it is locked. The PMC should consider adding a WARNING.txt file to the top-level of your old CVS repository, with a commit message to say that it is closed and you have moved to SVN (this also helps ViewCVS users).
7. Your CVS repository will be converted to Subversion and loaded into the test asf Subversion repository.
8. You and the project representatives will be asked to provide feedback in real-time about the layout that you provided. At this time, the infrastructure team will get the 'backroom' stuff configured (such as the mailer config and ACLs).
9. Once approval is made, your CVS repository will then be converted to Subversion and loaded into the main asf Subversion repository.
10. Then, you will need to send a notice to your project list that your project is now using Subversion. See the ASF documention on source code repositories for details on how to use Subversion at the ASF. Note that the biggest mistake that committers make is not using https to check out their working copy.
11. Enjoy!

Nicola Ken Barozzi wrote:
 >
 > The Cocoon project has decided to move to subversion, so we need your
 > help, along with an indication about when it can be done. TIA
 >
 > <quick-summary>
 > We need to export
 >
 >   cocoon-2.1
 >   cocoon-2.2
 >   cocoon-site
 >
 > to SVN and then lock these CVS modules.
 >
 > The resulting repo we need is:
 >
 >   /cocoon/
 >    /trunk/        (cocoon-2.1 HEAD)
 >    /tags/         (cocoon-2.1 tags)
 >    /branches/     (cocoon-2.1 branches)
 >      /new-kernel/ (cocoon-2.2 HEAD)
 >    /site/         (cocoon-site HEAD)
 >
 > </quick-summary>
 >
 > <long-version>
 >
 > Currently Cocoon has these repositories:
 >
 > cocoon-1/
 > cocoon-2-historical/
 > cocoon-2.0/
 > cocoon-2.1/
 > cocoon-2.2/
 > cocoon-lenya/
 > cocoon-site/
 >
 > But we don't need to convert all of them.
 >
 > These are frozen and can remain in CVS for now:
 >
 > cocoon-1/
 > cocoon-2-historical/
 > cocoon-2.0/
 >
 > Lenya should decide independently so it's not part of this move:
 >
 > cocoon-lenya/
 >
 > The modules we need to move are:
 >
 > cocoon-2.1/   ->  current trunk
 > cocoon-2.2/   ->  new kernel branch
 > cocoon-site/  ->  our site
 >
 > Basically, this is what we need:
 >
 > 1: convert cocoon-2.1 to SVN
 >
 >   cocoon-2.1 CVS
 >
 >        |
 >        |
 >        V
 >   /cocoon/
 >    /trunk/
 >    /tags/
 >    /branches/
 >
 > 2: convert cocoon-site to SVN without branches and tags, and place it
 >    under cocoon
 >
 >   cocoon-site CVS
 >
 >        |
 >        |
 >        V
 >   /cocoon/
 >    /site/
 >
 > 3: convert cocoon-2.2 without branches and tags to SVN and place it
 >    as a branch here
 >
 >   cocoon-2.2 CVS
 >
 >        |
 >        |
 >        V
 >   /cocoon/
 >    /branches/
 >      /new-kernel/
 >
 >
 > Thus resulting into:
 >
 >   /cocoon/
 >    /trunk/        (cocoon-2.1 HEAD)
 >    /tags/         (cocoon-2.1 tags)
 >    /branches/     (cocoon-2.1 branches)
 >      /new-kernel/ (cocoon-2.2 HEAD)
 >    /site/         (cocoon-site HEAD)
 >
 > </long-version>
 >

Guide for Infra volunteers who have svnadmin permissions.

CVS to SVN migrations are performed using the cvs2svn script on a copy of the cvs module to create a dump file, and then using svnadmin load to load it into the existing subversion repository. The migration process to load apache-foo into /tlp/foo should look something like the following.

On the first time around you will deploy to repos/test. The second time you will deploy to repos/asf. For the second time, replace repos/asf with repos/test in the script snippets below.

(if repos/asf) Prepare the community

1. Get permission to start the migration
2. It is recommended to have a volunteer from the community to double-check your work as you go
3. Lock CVS by commenting out the module's line in CVSROOT/avail
4. Have your volunteer confirm it is read-only

Create dump file

1. cp -r /home/cvs/apache-foo apache-foo
2. cvs2svn --dump-only --dumpfile=apache-foo-cvs2svn-dump apache-foo

In the test phase, this stage may throw up errors due to problems in the CVS files which will then need to be fixed (via script etc). Hopefully no new problems will be introduced between the test phase and the live phase.

Prepare the SVN repository

1. svn co -N https://svn.apache.org/repos/test/tlp/
2. cd tlp
3. mkdir foo
4. svn add foo
5. svn ci -m 'preparing for apache-foo migration' foo

You will need the permissions to do this, so you will probably need to belong to the svnadmin section in subversion's authorization file.

Load the dump file in

1. Switch user to nobody: sudo -u nobody -s
2. Confirm you have switched with 'whois'. Switching is important to avoid screwing the repository.
3. PATH=$PATH:/usr/local/svn-install/current/bin/
4. svnadmin load --parent-dir tlp/foo/ /x1/svn/test/ < apache-foo-cvs2svn-dump

You will need to have sudoer permission to switch to the nobody user.

(if repos/test) Notify community

1. Send email to community notifying them of the test repo and asking them to confirm it is correct and schedule a time for the repos/asf migration.

(if repos/asf) Setup asf-authorization

1. Copy the CVSROOT/avail line for apache-foo into the asf-authorization file.
2. Adjust the syntax to match the new files style.
3. Check the file into SVN, it gets updated automatically into the SVN installation.

(if repos/asf) Setup svn commit emails

1. Find out where the commit emails should go by asking the foo community.
2. Edit asf-mailer.conf. Chances are it will be pretty boilerplate.

(if repos/asf) Test the migration

1. Have your volunteer test that the new svn location checks out, that they can commit and that a message gets sent to the correct email list.

(if repos/asf) After deploying, clean up

1. rm /home/cvspublic/apache-foo
2. svn rm -m 'Now in asf repo.' https://svn.apache.org/repos/test/tlp/foo

To remove the cvspublic directory you will need to be a member of the cvsadmin unix group.