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 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//!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:\\db\\revs\\0\\135': End of file found [500,
> > #70014]
> >
> > svnadmin verify returns:
> >
> > * Verified revision 135.
> > svnadmin: E070014: Can't read file
> 'E:\\\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
>
