Switching to PlasticSCM & Dealing with Subversion corruption

So I’m switching over to PlasticSCM, and I’m trying to import my existing SubVersion repository.

The PlasticSCM importer was easy enough to configure, and at first I pointed it against the VisualSvn Server bin directory.  That didn’t work very well, and I immediately got a null-pointer exception.

So I downloaded the latest Windows binaries from http://subversion.tigris.org/getting.html#binary-packages

That worked better, but after a little while the import said that there was an error.  At first I thought it was a problem with PlasticSCM, but it wasn’t.  The PlasticSCM importer reported that there was a problem running the command:

svn log -v https://myserver/myproject

So I ran this command from the command line and eventually got this error back from Subversion:

Could not read chunk Size: Secure connection truncated

So after some Googling demonstrated that other people had this problem and nobody had a solution I configured VisualSvn Server to just use a non-secure connection, which then lead to this error:

Could not read chunk size: connection was closed by server

Okay…  So then I got smart and tried something slightly clever – I bypassed the server entirely:

svn log -v file:///d:/dev/Subversion/myproject

Now I finally got the REAL error message:

svn: Malformed file

So then I tried this:

svnadmin verify d:\dev\Subversion\myproject

But that reported that every revision verified just fine!?  But when I run the “svn log -v” again revision 147 still bombs, so it looks like “svnadmin verify” is not really doing a very good job.  The “svnadmin recover” command does nothing, and completes almost immediately saying that everything is fine.  (at this point, I am really not happy with Subversion – how many other internal corruptions are there?!)  I tried doing a dump of the repository:

svnadmin dump d:\dev\Subversion\myproject> d:\tmp\SubversionRepository.dump

but that also failed on revision 147.

Back to Google!  Apparently people are just hoping that the revision is early in the product development life cycle and then dropping all the revisions before that:  http://svn.haxx.se/users/archive-2006-10/0215.shtml.  Sigh.

So then I ran:

svnadmin dump –revision 148:HEAD d:\dev\Subversion\myproject > d:\tmp\SubversionRepository.dump

and got some error messages that things were referencing revision 145, which is before when I’m now dumping so loading into an empty repository will fail.  What’s really odd is that it didn’t stop there, it just kept going, so if I wasn’t watching it I might not have noticed that the dump was bad.  So I had to run it again, skipping even more revisions and starting at 153 – 8 revisions AFTER the corruption.

What good is a revision control system if the revision history silently becomes corrupted and the only solution is to drop all the revisions before that!?!? Sadly, I’m not alone:

• http://www.raditha.com/blog/archives/000666.html
• This one has a very interesting possible solution:
  http://subversion.open.collab.net/ds/viewMessage.do?dsMessageId=330642&dsForumId=3
• http://markmail.org/message/5u4wvc6mkri2q7eg
• and on, and on…

So with my partial dump completed I did a load into a new repository:

svnadmin create d:\dev\Subversion\myproject_fixed
svnadmin load d:\dev\Subversion\myproject_fixed < d:\tmp\SubversionRepository.dump

This command took a while to run, but it seemed to be successful.  I can now do a svn log -v against the repaired repository.

And the PlasticSCM importer is now working; Goodbye Subversion!

Subversion says: I’ve just sucked 2.5 hours of your life away.
[Robert cries and moans in pain]

Advertisements

« Switching to NLog

The PlasticSCM Evaluation: Not good so far, problems with ignore.conf »