//////////////////////////////////////////////////////////////////////////////////////
// CANNOT COMMIT TO SVN, SIMPLE SOLUTION
// 
// Bryan Smith, Friday May 9 2008
//////////////////////////////////////////////////////////////////////////////////////

Our web server, which also hosts our Subversion repositories, suffered a hardware failure, so we had to put together a new server post-haste. (We used one of the computers from my rack of eight boxes which I use for testing.)

It took a little ingenuity and a decent amount of work to recover some of the data, so to prepare for the future, I created a shell script that backups up all of our various database files and tarballs them to a separate drive. Never again, hopefully.

 I copied over the Subversion repository directories from the old disk and restarted the server:

--------------------
$ svnserve -d
--------------------

We could checkout and update our code just fine. However, we could not commit code changes to the server. This was testing on OS X, Ubuntu, and Windows XP and Vista.

We received various error messages, such as connection reset by peer and other messages about the connection becoming unexpectedly closed. (I wish I kept the exact messages to make this more searchable.)

The problem may have been related to permissions. In any case, I solved the commit problem by dumping the old repository, and creating a new repository and loading the data.

Say, for example, we are having problems with a repository at the path /svn/MY_REPOS/:

--------------------
# First, get the dump
$ svnadmin dump /svn/MY_REPOS > /MY_REPOS.dump

# Let's back up the old repository
$ mvdir /svn/MY_REPOS /svn/~MY_REPOS

# Create a new repository
$ svnadmin create /svn/MY_REPOS

# Load the dump
$ svnadmin load /svn/MY_REPOS < /MY_REPOS.dump    

# If everything was fine, why not delete the dump?  
# It's probably pretty large  
$ rm /MY_REPOS.dump 
--------------------

Everything works fine again. I also wrote a shell script to dump all of our SVN repositories and tarball them to another drive. These are quite large files, so it only keeps the four most recent repositories.

This seems far simpler to me than trying to resolve any issues, permissions or otherwise.