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.s_at_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
Received on 2018-03-07 22:10:10 CET