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.)
Received on 2012-01-12 13:01:57 CET