I converted my personal CVS repository to Subversion, running on Mac OS X, today. Here are a few notes...

Subversion Package

The first question (until Mac OS X Tiger arrives) is what packages to install on both client and server, i.e. if a simple client-only package is enough for both sides, or if a more elaborate server installation (with apache2 http server and WebDAV module) is required. Right now a simple svn+ssh connection to my machine hosting the repository is good enough for me, so I don’t need a real server installation. If I ever do, I will probably use DarwinPorts according to the notes by James Duncan Davidson.

There are several Subversion client-side packages around. I ended up using the non-fink binary version linked to from the official Subversion download page. Installation worked flawlessly on both machines and I’m very happy with it.

Repository Conversion Preparation

After installing Subversion onto the server, I converted my existing CVS repository into a Subversion repository using the cvs2svn migraton tool. I used version 1.2.1 (support for the Subversion repository backend type “fsfs”, which I wanted to use, seems to be available since version 1.2).

cvs2svn is written in Python, which is already installed on Mac OS X Panther, but it requires a recent version of a Berkeley DB extension module, which is not included. I downloaded, built and installed both the Berkeley DB package (version 4.3) and the Python wrapper for it, called bsddb3 (version 4.3.0). Installation was very easy for both as described in their respective README files:

Inside the Berkeley DB distribution package, run

cd build_unix
../dist/configure
sudo make install

Inside the Pybsddb distribution package, run

python setup.py build
sudo python setup.py install

You can check if everything is installed correctly by invoking cvs2svn without parameters in its distribution directory:

./cvs2svn

It will complain if the DB modules are missing, and print a list of options if everything is OK.

The Actual Conversion

I tried the conversion twice, the way it worked correctly in the end was

./cvs2svn --no-default-eol --fs-type=fsfs -s /Users/liyanage/Documents/svnroot /Users/liyanage/cvsroot

The first time I ran it without the --no-default-eol option, which corrupted lots of binary files like images and .nibs in my projects.

The --fs-type=fsfs option creates the repository with the filesystem-based storage backend, which I prefer after reading about the differences between fsfs and the older option, storage of the data in DB files.

The -s option supplies the location of the new repository to be created, and the last argument is the existing CVS repository. cvs2svn does not modify anything in the CVS repository, it’s strictly read-only.

Working with the new Repository

Before the conversion, I closed up all projects in my CVS sandboxes and did one last commit, as the conversion with cvs2svn is one-shot only.

I literally know nothing about Subversion, but since the basic commands are so similar to CVS, I was able to checkout my migration “test case”, my Cocoa application TestXSLT, without any problems. As mentioned above, the first time around everything was broken because of the missing --no-default-eol flag, but the second time the app built and ran fine.

I plan some major directory layout adjustments in my source directory for TestXSLT, which is why I wanted to move to Subversion in the first place. I already love “svn rm” and “svn mv” :-)

Next on the list is some reading in the Subversion Book.