BEFORE converting, you must ensure that all binary files
have the '-kb' option set in CVS. This can be done with cvs admin -kb
$FILE. Otherwise, the converted files will be corrupt
with Subversion.
Users who haven't used Subversion before need to log into
minotaur.apache.org and run the svnpasswd utility to set their
Subversion password.
- Your project's PMC has to decide that it's ready to convert to
Subversion.
- 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.
- 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.
- 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.
- 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.
- 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).
- Your CVS repository will be converted to Subversion and loaded
into the test asf
Subversion repository.
- 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).
- Once approval is made, your CVS repository will then be converted to
Subversion and loaded into the main
asf Subversion repository.
- 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.
- 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
- Get permission to start the migration
- It is recommended to have a volunteer from the community to double-check your work as you go
- Lock CVS by commenting out the module's line in CVSROOT/avail
- Have your volunteer confirm it is read-only
Create dump file
cp -r /home/cvs/apache-foo apache-foo
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
svn co -N https://svn.apache.org/repos/test/tlp/
cd tlp
mkdir foo
svn add foo
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
- Switch user to nobody:
sudo -u nobody -s
- Confirm you have switched with '
whois
'. Switching is important to avoid screwing the repository.
PATH=$PATH:/usr/local/svn-install/current/bin/
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
- 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
- Copy the CVSROOT/avail line for apache-foo into the asf-authorization file.
- Adjust the syntax to match the new files style.
- Check the file into SVN, it gets updated automatically into the SVN installation.
(if repos/asf) Setup svn commit emails
- Find out where the commit emails should go by asking the foo community.
- Edit asf-mailer.conf. Chances are it will be pretty boilerplate.
(if repos/asf) Test the migration
- 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
rm /home/cvspublic/apache-foo
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.