When the corruption happens, our replication system, which uses svnsync, sees this error:
svnsync: E175002: REPORT request on '/path/to/repo' failed: 500 java.lang.ArrayIndexOutOfBoundsException at org.tmatesoft.svn.core.io.diff.SVNDiffWindow.apply(SVNDiffWindow.java:360) at org.tmatesoft.svn.core.internal.delta.SVNDeltaCombiner.addWindow(SVNDeltaCombiner.java:225) at org.tmatesoft.svn.core.internal.io.fs.FSInputStream.getContents(FSInputStream.java:171) at org.tmatesoft.svn.core.internal.io.fs.FSInputStream.readContents(FSInputStream.java:114) at org.tmatesoft.svn.core.internal.io.fs.FSInputStream.read(FSInputStream.java:98) at org.tmatesoft.svn.core.internal.wc.SVNFileUtil.readIntoBuffer(SVNFileUtil.java:309) at org.tmatesoft.svn.core.io.diff.SVNDeltaGenerator.readToBuffer(SVNDeltaGenerator.java:279) at org.tmatesoft.svn.core.io.diff.SVNDeltaGenerator.sendDelta(SVNDeltaGenerator.java:154) at org.tmatesoft.svn.core.internal.io.fs.FSReplayPathHandler.handleCommitPath(FSReplayPathHandler.java:228) at org.tmatesoft.svn.core.internal.wc.SVNCommitUtil!
.driveCom
mitEditor(SVNCommitUtil.java:134) at org.tmatesoft.svn.core.internal.io.fs.FSRepositoryUtil.rep
...and normal client operations see the same symptom. If I run "svnadmin verify" on the repository, I see something like this:
...
* Verified revision 262.
svnadmin: E160004: Filesystem is corrupt
svnadmin: E200014: Checksum mismatch while reading representation:
expected: db206cf419e73630c8098878d0908e65
actual: 4b9c123413a97eacd3c487a14aed50ec
"svnadmin recover" won't fix this. All I can do is dump and restore the repository, discarding the bad revision. The users then commit the same files again, and everything is fine.
I've saved some of these bad repositories. I can use vi or hexedit to open (in this case) db/revs/0/263 and search for the expected checksum. That tells me which file has the bad checksum. In all cases so far, the file has been a binary file of some type.
I haven't been able to reproduce this problem myself, so I don't know if the users are doing anything peculiar; regardless, no combination of network inputs should result in a corrupted repository. Does anybody have suggestions on how I can troubleshoot this better?
Chris
--
You received this message because you are subscribed to the Google Groups "scmmanager" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scmmanager+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Sebastian,
Any progress on this? We haven't seen any recent repository corruption, but I'm hesitant to fully trust SCM Manager with our Subversion repositories right now.
Chris
You received this message because you are subscribed to a topic in the Google Groups "scmmanager" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scmmanager/r1wlKUN8oEQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scmmanager+...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to scmmanager+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "scmmanager" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scmmanager/r1wlKUN8oEQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scmmanager+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "scmmanager" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scmmanager+unsubscribe@googlegroups.com.
Okay, thanks for the status update.
Chris
To unsubscribe from this group and all its topics, send an email to scmmanager+...@googlegroups.com.