Qef's Website

(These are some notes I made while migrating the GBdirect website to Subversion. Before that we stored it in CVS.)

(Update: there is now some decent documentation about the various ways of using cvs2svn, which is probably more useful than this article.)

Migrating our website from CVS to Subversion seems to have gone fairly well. I've still got a few wrinkles to iron out, and it'll take us all time to get used to the slightly different svn command, but the advantage of being able to track file moves and renames will make our lives a lot easier. No longer will we have to manually set up redirects whenever someone decides they want to rename a training course, or whatever.

You can use the cvs2svn program to import the files, along with all the revision history. Assuming the CVS repository is in a directory called cvs and you want to put the subversion database in one called svn, here's how to run it:

mkdir svn
cvs2svn.py -s svn/website cvs/website

(if website is what the CVS module was called, and we want to keep the same name in Subversion.)

(Update: the cvs2svn program is now in Debian in the package of the same name. Also, it may be a good idea to use the options relating to mime types and keywords to get appropriate svn properties set in your new repository.)

Here's how to get a working copy when you're on the same machine as the repository. I haven't bothered setting up the webdav stuff, so we access the files directly. You need to give a full path, as a file URL, of the bit of the repository you want to get:

svn co file:///var/lib/svn/website/trunk website

The trunk bit on the end means we want the main version rather than a branch. You can create branches just by using the svn copy command to copy the trunk into something like website/whatever and then checking that out instead.

For remote access we're using SSH to check things out, since that seemed simpler than setting up all the fancy webdav stuff in Apache:

svn co svn+ssh://devel/var/lib/svn/website/trunk website

(Where devel is the name of the server, or in my case a synonym set up in ~/.ssh/config.)

Dealing with .cvsignore files

One other little problem was that we had quite a few .cvsignore files left lying around. The current version at least of cvs2svn doesn't do anything clever with these, and they don't mean anything special to Subversion. Instead, Subversion uses a special ‘property’ called svn:ignore to store the list of files and patterns for what it's not meant to be managing.

To convert your .cvsignore files to Subversion properties, just go to a working copy with no changes in and run this little bit of shell script (just copy it into Bash):

for f in $(find . -name .cvsignore); do
    svn propset svn:ignore -F $f $(dirname $f);
    svn rm $f;
done

(Update: this is no longer necessary with more recent versions of cvs2svn, since it now converts .cvsignore files into svn properties automatically. You'll just want to delete the .cvsignore files after the conversion.)

That sets the properties and deletes the files. It only affects your working copy. You'll want to run svn status to check that everything's OK, and then commit the whole lot with svn commit.