Paul E writes:
> * Verified revision 135.
> svnadmin: E070014: Can't read file 'E:\\\db\revs\0\135':
> End of file found
This looks like a rep-caching bug: r136 is using the wrong offset into
r135. It appears to be issue 4277 although I'm not aware of anyone ever
triggering it before:
http://s
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
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
Guten Tag Paul E,
am Donnerstag, 10. Januar 2013 um 21:11 schrieben Sie:
> 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 an
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).
Upon checkout, we get the following message:
REPORT of '/svn//!svn/me': Could not read chunk size: Secure
connection truncated
Apache logs show:
