On 11/09/2010 06:41 PM, Daniel Shahaf wrote:
> Edward Ned Harvey wrote on Sat, Nov 06, 2010 at 20:29:18 -0400:
>>> From: opensrcguru [mailto:opensrcguru_at_gmail.com]
>>>
>>> Today, the sync process started failing on 1 repo (all others were
>>> unaffected) on both r/o copies at the exact same time/same revision
>>> with errors similar to the following...
>>>
>>> Transmitting file data .svnsync: Base checksum mismatch on
>>> '/path/to/file/foo/bar':
>>> expected: 2f2e025c4c4855e7466799a877b3e23d
>>> actual: 272214b9518d352e16e7eeceeb22f573
>>
>
> Can you compare the contents of /path/to/file/foo/bar between the master
> and mirror, as of the last revision successfully synced to the mirror?
Yes, I had done that and yes, the last sync'd revs were in tact and accurate.
> If you create a fresh mirror and svnsync it, from r0 to that revision,
> does the file /path/to/file/foo/bar in the fresh mirror differ from the
> one in the master?
No, a resync from r0 to current does not result in any differences.
> What versions of everything are you using?
Looks like that part was chopped out at some point. both r/o copies as well as the r/w copy are at version 1.6.13 (r1002816)
>
> What format are the repositories? (What are the contents of the files
> $REPOS_DIR/db/fs-type and $REPOS_DIR/db/format?)
both r/o copies as well as the r/w copy are the same:
root_at_host:reponame/db #>cat format
4
layout sharded 1000
root_at_host:reponame/db #>cat fs-type
fsfs
>> I recently had the same problem. I never found any cause for it, but
>> I did manage to deal with it somewhat better than you did. On the
>> master, I did svnadmin hotcopy, then I tarred up the backup and sent
>> it to the slave, and extracted it. I had to configure the slave hook
>> scripts, and the revprop rev 0 properties, and then I was able to
>> svnsync to the slave again. The main point of difference ... No need
>> to wait for 65k commits to transfer. Since it's starting from
>> a recent backup, it's enormously faster.
>>
Received on 2010-11-10 03:59:39 CET