0

I just had an issue where a newly created Subversion repository had around 80% of its revisions corrupted (the user received filesystem corruption and checksum mismatch errors when it eventually became unusable). However, the engineer was able to work with the repository and even create a branch from one of the corrupted revisions and update those revisions until the errors mentioned above started occurring. Since the project was only a week old, we ended up deleting and recreating it, but this could have been a lot worse had this been a project with a lot of history. I've dealt with repository corruption before, but some of the behavior I saw when diagnosing the repository really throws me for a loop, and I'm hoping to gain some insight into what might have happened.

What was really strange about this is that if I checked out the project's HEAD revision, I got the checksum mismatch and filesystem corrupt errors myself. However, if I checked out revision 1, then sequentially updated to each individual revision including the known corrupted revisions, these errors never occurred and it was like nothing was wrong with the repository ('svnadmin verify' confirmed that there was indeed corruption, and 'svnadmin dump' failed with the same errors on each corrupted revision). Generally, corrupted revisions fail to be updated to, which is why I'm very confused as to what has happened here.

This is the strangest repository issue I've seen in 6 years, and I'm hoping someone more knowledgeable than I can help me gain insight into what might have gone wrong. I have a backup of the repository so I am able to pull whatever information may necessary for diagnosis.

We are currently using SCM Manager to host Subversion and Git projects, but we haven't seen anything like this happen since we started using SCM Manager as a source control platform. We use TortoiseSVN 1.8 against 1.7 compatible repositories (svnsync has serious issues in 1.8, so we use 1.7 for this), but some of us do use the command line svn tools as well. In this case, TSVN was the client used on this repository, my own testing was done via the command line version.

Improve this question
3
  • I suppose it depends on what backend your svn is using. I have some old (standalone, not under scm manager) svn repos, they use fsfs which stores revisions under repo_path/db/revs/. I could use svnadmin verify to search for corrupted revisions then have a look at actual revision file contents.
    – Dan
    Jun 25, 2015 at 19:43
  • We're using FSFS on the backend. I wouldn't touch BerkeleyDB with a 10 foot pole.
    – codewario
    Jun 26, 2015 at 12:25
  • Well then, can you use svnadmin verify to isolate corrupted commits, then have a look at the actual files (they have some binary stuff but at least on mine actual code is not compressed or anything so it may give you a hint of how bad it is)?
    – Dan
    Jun 26, 2015 at 17:15

1 Answer 1

Reset to default
0

I was able to isolate the cause, it seems to be from an incomplete commit that was somehow not thrown out when the commit failed.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .