On 26.02.2018 22:41, Myria wrote:
> -bash-4.1$ sqlite3 rep-cache.db "select * from rep_cache where
> hash='db11617ef1454332336e00abc311d44bc698f3b3'"
> db11617ef1454332336e00abc311d44bc698f3b3|604440|34|134255|136680
>
> The line from the grep -a command containing that hash is below. They
> all match.
> text: 604440 34 134255 136680 c9f4fabc4d093612fece03c339401058
> db11617ef1454332336e00abc311d44bc698f3b3 604439-cyqm/_13
>
>
> In other news, unknown whether related to the current problem, my
> attempt to clone the repository to my local computer is failing:
>
> D:\>svnsync sync file:///d:/svnclone
> Transmitting file data
> .....................................................................................................................................................svnsync:
> E160000: SHA1 of reps '227170 153 193 57465
> bb52be764a04d511ebb06e1889910dcf
> e6291ab119036eb783d0136afccdb3b445867364 227184-4vap/_4o' and '-1 0
> 193 57465 bb52be764a04d511ebb06e1889910dcf
> e6291ab119036eb783d0136afccdb3b445867364 227184-4vap/_4o' matches
> (e6291ab119036eb783d0136afccdb3b445867364) but contents differ
> svnsync: E160004: Filesystem is corrupt
> svnsync: E200014: Checksum mismatch while reading representation:
> expected: bb52be764a04d511ebb06e1889910dcf
> actual: 80a10d37de91cadc604ba30e379651b3
>
> This is odd, because revision 227185 (the revision it's trying to
> commit) verifies fine on the originating server:
>
> -bash-4.1$ sudo svnadmin verify -r227170 /srv/subversion/repositories/meow
> * Verifying repository metadata ...
> * Verifying metadata at revision 227170 ...
> * Verified revision 227170.
> -bash-4.1$ sudo svnadmin verify -r227185 /srv/subversion/repositories/meow
> * Verifying repository metadata ...
> * Verified revision 227185.
It is a very, *very* bad idea to perform any operations on the
repository as root! You should not have to do that.
Please check file ownership and permission throughout the repository;
none of the files should be owned by root.
-- Brane
> On Fri, Feb 23, 2018 at 5:42 PM, Philip Martin <philip_at_codematters.co.uk> wrote:
>> Philip Martin <philip_at_codematters.co.uk> writes:
>>
>>> There are a couple of options:
>>>
>>> A) disable rep-caching by editing fsfs.conf inside the repository
>>>
>>> B) reset the mapping by deleting/renaming the file db/rep-cache.db
>>> inside the repository (but please rename rather than delete if you
>>> want to help us identify the corruption)
>>>
>>> Doing either of these should allow the commit to succeed.
>> To verify the corruption start with the rep-cache:
>>
>> sqlite3 db/rep-cache.db "select * from rep_cache where hash='db11617ef1454332336e00abc311d44bc698f3b3'"
>>
>> That should give you five numbers: the hash, the revision (604440), the
>> offset, the size and the expanded size.
>>
>> Then examine the revision file for r604440. It could be unpacked:
>>
>> grep -a "^text: 604440.*/_" db/revs/604/604440
>>
>> or packed:
>>
>> grep -a "^text: 604440.*/_" db/revs/604.pack/pack
>>
>> One of the lines from grep should contain the hash and that line should
>> start:
>>
>> text: 604440
>>
>> followed by three more numbers then hashes and other stuff. The three
>> numbers are the offset, size and expanded size and should match the
>> values from the rep-cache but I suspect the rep-cache has the wrong
>> offset.
>>
>> --
>> Philip
Received on 2018-02-27 08:45:22 CET