-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.
On Fri, Feb 23, 2018 at 5:42 PM, Philip Martin <phi...@codematters.co.uk> wrote:
> Philip Martin <phi...@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
