Friday, February 03, 2006

How to Salvage a Subversion Screw-Up

Yesterday, one of the developers at work attempted to add approximately 14,000 files to one of our subversion (aka svn) source control repositories. The svn server itself resides on a linux box, but the interface the developer used was TortoiseSVN, a Windows explorer based interface that is pretty slick.

Anyhow, the attempted addition of 14K files caused TortoiseSVN to choke. Futhermore, actually checking out the repository with all of these files added takes almost an eternity in developer time, and also causes TortoiseSVN to choke.

So, I knew what I had to do - remove the files added in the offending transaction. Now, how do I do that?

After a bit of googling about and reading through the administration chapters of the svn book, I realized that I would have to dump the repository (minus the offending transaction), and then rebuild a new one.

Looking over Trac (our project management app that integrates nicely with svn and provides bug/ticket tracking etc.), I found that revision 688 was the culprint. Thus, after a bit of trial and error, I finally zeroed in on the following comman (executed from the bash shell on the linux box) to dump the repository as desired:

svnadmin dump [repository path] --deltas --revision 1:687 | gzip > ~/dumpfile.gz

Next, I renamed the old repository directory to [repository path].old, and created a new repository to fill back up.

Finally, the step I was waiting for - loading the new repository up with the good transactions:

gunzip -c ~/dumpfile.gz | svnadmin load [repository path]

After a few minutes of churning away, svn finally notified me that revision 687 was committed, and I am now ready to go! Woo-hoo!


  1. LOL. Do we get to guess who it was???

  2. Hehehe - actually it was Mo, and it wasn't her fault entirely... ;>

  3. Well, I had a 25% chance. Or 33%, depending on who you're asking. :p