Branko Čibej <brane_at_apache.org> writes:
> On 22.02.2018 21:30, Myria wrote:
>> When we try to commit a very specific version of a very specific
>> binary file, we get a SHA-1 collision error from the Subversion
>> repository:
>>
>> D:\confidential>svn commit secret.bin -m "Testing broken commit"
>> Sending secret.bin
>> Transmitting file data .svn: E160000: Commit failed (details follow):
>> svn: E160000: SHA1 of reps '604440 34 134255 136680
>> c9f4fabc4d093612fece03c339401058
>> db11617ef1454332336e00abc311d44bc698f3b3 605556-czmh/_8' and '-1 0
>> 134255 136680 c9f4fabc4d093612fece03c339401058
>> db11617ef1454332336e00abc311d44bc698f3b3 605556-czmh/_8' matches
>> (db11617ef1454332336e00abc311d44bc698f3b3) but contents differ
>>
>>
>> What can cause this?
>
> The simplest explanation would be a corruption of the existing
> representation on disk. Note that both the MD5 and the SHA1 checksums
> appear to match, as do the sizes; which makes it even more likely that
> it's the same file but the copy in the repository is somehow corrupted.
That pattern, all of MD5, SHA1 and size matching, is exactly what
happens if a SHA1 collision is committed using an old version of
Subversion where the rep-cache does not detect collisions. The first
part of the collision would have been committed in r604440 and the
second part in r605556.
If that is the case, and a SHA1 collision did occur, then:
svnadmin verify -r604440 path/to/repository
will succeed while:
svnadmin verify -r605556 path/to/repository
will fail with an MD5 checksum error.
If this is what you see then unfortunately the colliding r605556 content
has been elided and the r605556 revision is corrupt.
You should be able to retrieve the first part of the collision from
r604440, it will be one of the files given by:
svn log -v -r604440
The second part in r605556 is missing :-( but it will be one of the
files given by:
svn log -v -r605556
However your failing commit would also be a SHA1 collision with the
r604440 content (it might be identical to the missing content in
r605556).
--
Philip
Received on 2018-02-23 02:33:53 CET