I found myself restoring a subversion repository from a backup earlier today, and discovered it’s not as simple as one might imagine.

Our repository had been up to about revision 7600, but the backup was back around 7560, which wasn’t exactly a disaster as all the changes still existed in the working copies. However, trying to do anything with the working copies results in a subversion error saying, in effect, that revision 7600 (which is what the working copies were up to) doesn’t exist.

Unfortunately, since we’re using subversion to manage the configuration of a number of servers, messing directly with the working copies isn’t really an option, so I’m left with he rather painful task of trying to hack things back together. I’ve got most of a perl script to checkout a new working copy then slam all the .svn directories in the real working copy. In my tests, that’s allowed me to re-check in all the changes again without any major drama, so assuming that all goes smoothly on the real systems, I’ll see if the perl script can be pulled into a distributable state.

You would imagine this is the sort of thing that there would be a standard solution for though, but google was only able to pull up suggestions along the lines of what I’m doing here. I’ve not tried it, but someone at work did suggest making a bunch of fake revisions to bring the revision number back in line. I suspect that wouldn’t work correctly, but I’d love to hear if anyone’s tried it.

Technorati Tags: , , ,