Apologies, I failed to mention that I had upgraded VisualSVN Server from 2.5.6 to 2.5.8 after the first repository exhibited corruption. I have not tried VisualSVN 2.5.7.
I have looked into potential hardware issues, but am fairly confident that's not the issue. This is fully redundant server with a RAID drive configuration and hardware tests are all checking out. For further specifications, this is a 64-bit Windows 2008 R2 machine. On Fri, Jan 11, 2013 at 11:37 AM, Stefan Sperling <s...@apache.org> wrote: > On Thu, Jan 10, 2013 at 02:11:04PM -0600, Paul E wrote: > > Hi, > > > > We're having an issue that has occurred three times in the past two weeks > > with two different repositories hosted with VisualSVN (version 2.5.8). > > VisualSVN 2.5.8 is pretty recent. Did this start happening after an > upgrade/install of 2.5.8? Have you tried downgrading to 2.5.7 to see > if that fixes the issue? > > VisualSVN 2.5.8 includes Subversion 1.7.8, which has the following change > in the FSFS filesystem code: > * fix fs_fs to cleanup after failed rep transmission (r1403964, et al) > > Maybe what you are seeing is a regression introduced with that fix? > > Please confirm if possible. Thanks! > > BTW, a similar issue has been reported here: > http://svn.haxx.se/users/archive-2013-01/0029.shtml > > > Upon checkout, we get the following message: > > > > REPORT of '/svn/<project>/!svn/me': Could not read chunk size: Secure > > connection truncated > > > > Apache logs show: > > > > [Wed Jan 02 20:59:20 2013] [error] [client xxx.xxx.xxx.xxx] A failure > > occurred while driving the update report editor [500, #70014] > > [Wed Jan 02 20:59:20 2013] [error] [client xxx.xxx.xxx.xxx] Can't read > file > > 'E:\\<SVNPath>\\<Project>\\db\\revs\\0\\135': End of file found [500, > > #70014] > > > > svnadmin verify returns: > > > > * Verified revision 135. > > svnadmin: E070014: Can't read file > 'E:\<SVNPath>\<Project>\db\revs\0\135': > > End of file found > > > > This is a major issue for us as we're actively developing against these > > projects and having to recommit over and over again. Currently resolving > > the issue by creating a dump to the revision prior to the truncation and > > then loading into a new repository, but this is costing development time. > > > > Thanks for advance for your help. > > > > Paul >
