CompleteFusion

When I embarked on my first subversion to git migration recently, I thought it would be fairly easy — after all, migrating from CVS to subversion wasn't very difficult. Unfortunately, it wasn't as easy as I had thought, because I couldn't readily find reliable information to guide me. Since I had to spend entirely too time searching and testing various migration methods, I hope this post will help you avoid a similar fate.

The first step in migrating a repository from subversion to git is to get a list of committers from svn. There's no native way of requesting that information from subversion, but you can use svn log and grep the lines with revision data. If your subversion repository is on a remote host, you can use http to retrieve it and list all subversion commiters:

svn log --quiet http://www.foo.com/path/to/svn/ | grep '^r' | awk -F\| '{print $2}' | sort -u > committers.txt

If your subversion repository is hosted locally, just use file:///path/to/svn (note the three slashes in file:///, instead of two for http://).

After you have the list of subversion committers, create a users.txt file to map svn committers to git users, using the following format:

svnuser = Full Name <email@domain.com>

Although some people suggest using a basic git-svn migration or the svn2git scripts, I found the git-svn-abandon scripts to be the easiest and most sane. After downloading git-svn-abandon and putting the scripts somewhere in your PATH, you can start the migration process:

git svn clone --prefix=svn/ --stdlayout --authors-file=users.txt http://www.foo.com/path/to/svn/

Then cd into the directory the git-clone command just created and run:

git svn-abandon-fix-refs
git svn-abandon-cleanup

Finally, clone the new repository to make it sharable and configured for use:

cd ..
git clone --bare /path/to/git_svn/repo /path/to/shared_git/repo.git
cd /path/to/shared_git/repo.git
git --bare update-server-info
mv hooks/post-update.sample hooks/post-update

For more information, take a look at the git-svn-abandon author's article about Migrating from Subversion to Git.

Edited: I reported this issue to Debian and Christian Kastner patched it. Debian cron versions 3.0pl1-110 and higher should behave properly.

As reported in Ubuntu bug #151231 and at stackoverflow, cron jobs can fail silently when too much output is produced and an MTA is not installed.

Although the comments in the Ubuntu bug indicate that Debian is not affected because it includes the exim MTA by default, using a Debian VServer only installs the most basic packages – no MTA. I encountered this bug today while I was working on a backup script for a Subversion repository that runs in a Debian-based VServer. I previously discussed svn backupsand my script was using the same svnadmin dump technique I mentioned in that post.

When I ran the backup script manually, everything worked as intended and it produced a ~1.3GB backup file; however, when it ran under cron, the backup file was only ~2MB. Since the simplest solution is usually the correct one, I didn't initially suspect a bug in cron as the problem and tried to troubleshoot my script/environment. I eventually found the two links I listed above, where others have encountered the same bug.

It appears that the bug in cron causes it to silently fail when too much output is directed to STDERR without an MTA being present. In the case of svn backups, using the "quiet" flag (-q) for svnadmin dump is a possible workaround. In other cases, either redirecting STDERR to /dev/null or setting MAILTO="" in /etc/default/cron seem to be valid workarounds.