On Thu, Jan 12, 2012, at 13:40, D D wrote: > Daniel, > > Is your answer based on the knowledge of the code of the subversion server? >
Yes > Here are some details: > 1. It is not Unix [cp(1)], the problem was on Windows > 2. The disk looks fine (I ran chkdsk and looked at the SMART data). No > errors in the Windows log files. > 3. The svn repository did not change since the problem was detected and I > compared the corrupt hot copy to a correct one. There are 7940 files in > each. Of these, the contents of 28 files are not the same (file sizes are > ok). These 28 files are of various sizes but the first one (2255) is rather > large - 1.5 MB. The repository size is about 1GB. The data in the rev files > of the bad copy is corrupted from positions 0x1000 (first and second file), > 0x4000, 0, 0x1000, 0, 0, 0x4000, 0, 0, 0, 0x4000 etc. The corrupted file > numbers are not sequential (2255 corrupted, 2256-2270 ok, 2271 corrupted). I don't understand. Anyway: after a hotcopy, the revs/ and revprops/ trees of the source/dest of the hotcopy will be BYTE FOR BYTE IDENTICAL. (If you commit while a hotcopy is running, the commit may or may not be included in the copy, but the destination's integrity is guaranteed anyway and all other revision files will be identical still.)
