On 1/12/2012 4:51 AM, D D wrote:
On Thu, Jan 12, 2012 at 3:41 PM, Andy Levy <andy.l...@gmail.com
<mailto:andy.l...@gmail.com>> wrote:
Have you run svnadmin verify against the *actual* repository?
Yes. No problem detected.
If you make a new hotcopy of the repository, is that corrupted as
well?
No. I've only got a corrupted hot copy once in the last two weeks
(backups are daily).
Before that the repository was hosted on another WinXP system with
an earlier version of the Subversion server. I only added the call to
verify
the hot copy to the backup script recently so I do not know if the problem
ever occurred with the repository on the other system.
I'd be interested to know if svnadmin employs some memory buffer to
hot-copy.
The offsets where data corruption starts look like multiples of 0x1000
which is 4K.
The NTFS cluster size on the disk is exactly 4K.
If svnadmin just calls the OS to copy each file the problem should
either be in the OS
or the disk.
This really, really, really looks like a hardware problem or an
OS-related corruption. I agree with Andy Levy - Windows XP is not a
good OS to use as a server; it's 10 years old and they still haven't
bothered to fix bugs that I can invoke on a daily basis (most commercial
backup programs will cause a Windows service to go into an infinite loop).
Upgrade if you possibly can. Linux is free and runs on cheap hardware,
so I recommend it rather than try to find a Windows version that is
inexpensive but can still act as a server.
The fact that the problem is intermittent also points to something
outside of Subversion.
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
