The fulltext whose checksum is 80a10d37de91cadc604ba30e379651b3 I found out is the first 16384 bytes of the file (see other parts of this thread). 16384 is SVN__STREAM_CHUNK_SIZE.
On Fri, Mar 2, 2018 at 3:07 PM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Daniel Shahaf wrote on Fri, Mar 02, 2018 at 22:57:51 +0000: >> Myria wrote on Mon, Feb 26, 2018 at 13:41:05 -0800: >> > 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 >> >> When this error happens, could you print the first lines of the two reps >> identical? The first line is "PLAIN\n" or "DELTA\n" or "DELTA 42 43 44\n". >> (I wonder whether we have some stray whitespace that's transparent to parsing >> but breaks checksums.) > > In second thought I'm not sure this makes sense. A better question is: can we > obtain the fulltext whose checksum is 80a10d37de91cadc604ba30e379651b3? > >> Do you happen to have a copy of the repository lying around that you can run >> 'grep -a 80a10d37de91cadc604ba30e379651b3 db/revs/{0,1,2,...,227}' on? >> Admittedly that's a bit of a shot in the dark. >> >> Cheers, >> >> Daniel