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 <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
