4

Background:

I run VisualSVN on a windows server.

Problem:

I started getting errors on my nightly SVN hotcopy (svnadmin: E200002: Serialized hash missing terminator). I tried unsuccessfully to determine the source of the error and SVNADMIN VERIFY/RECOVER were returning no errors so I decided to try a dump & load.

This seemed to work successfully but when I renamed the test repository to the same name as the old one I got the error 'Corrupt node-revision'. I tried not loading the last few revisions (i.e. dumped until a few earlier) and I still get the same problem. When I rename it back to another name the problem stops. See follow-up - I'm not sure why but re-installing a new version of VisualSVN fixed the naming problem; I'm still unsure what caused it.

The questions I am hoping to have answered are:

  • What was likely to cause the original error?
  • Why would the name of a repo impact it's viability? (This may be VisualSVN cache thing - is it possible to fix it so I don't have to switch all the users working copies?)
  • Can I do anything to stop either issue happening in the future?

Follow up: After deciding the name change was almost certainly some issue with VisualSVN I uninstalled the version I was running (2.6.5) and moved to the current version (2.7.3). I pointed it to the same repositories folder and after installation everything worked! I'm not sure if re-installing the same version would have fixed the issue but as I haven't put too much time into configuring VisualSVN (since I originally migrated the repositories in) I didn't have much to lose..

Ewanw
  • 728
  • 11
  • 30

1 Answers1

2

I experienced the same issue in VisualSVN 3.2.2. While re-installing the application would solve the problem, I was able to solve the problem by restarting the VisualSVN Server service.

I've submitted a bug report to VisualSVN (they don't appear to have a public issue tracker).

tobylaroni
  • 843
  • 8
  • 16
  • Here was the response from the VisualSVN support team: "This is not actually a bug or a repository corruption. Apache Subversion keeps some repository data in memory cache and server restart flushes the cache. Roughly speaking, after you perform the reproduction steps (the third step), cache for the deleted repository is still there and it attempts to be applied to the new repository, thus you get the error." – tobylaroni Apr 15 '15 at 15:32
  • And as a followup "I'm glad to tell you that the behavior will be improved in the upcoming Apache Subversion 1.9 major release. In fact, our developers already fixed this in Subversion itself, so the future VisualSVN Server release linked against Subversion 1.9 won't require service restart after such dump-load-renameintooriginal process." – tobylaroni Apr 15 '15 at 15:34