Re: SHA-1 collision in repository?

Stefan Sperling <stsp_at_elego.de> writes:

> On Fri, Feb 23, 2018 at 01:06:36PM -0800, Myria wrote:
>> The revision 605556 is simply the current revision number of the
>> repository at the time of the attempted commit, and is unrelated to
>> the problem. If I attempt the commit now, it's a higher number, but
>> otherwise the same error message.

Yes, sorry, I misinterpreted the error message.

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

The commit is attempting to create r605556 by reusing data from r604440
but this fails the final stage of the commit when the fultext in the new
revision doesn't match the fulltext in the transaction.

>> Something I did notice is that the commit I'm trying to do is a
>> reversion to an older version of the same file. The revision of the
>> file throwing the error at 604440 is identical to the file I'm trying
>> to commit, but the file currently in the repository is different.

In that case there is probably no SHA1 collision.

>> If I commit a dummy version of the file, then commit the version I
>> actually want, the latter commit works. Could the collision be in a
>> "diff" instead of the files themselves?

The SHA1 reuse doesn't rely on the history of the file, it is a global
mapping across the repository of file content to checksum. The
collision is between fulltexts of the files, not diffs.

The only way I can explain the dummy commit is if the real file being
committed had svn:keywords or svn:eol-style properties and you did not
have the same properties when you committed the dummy file.

I think this might be the case since you mentioned earlier that you
could not find a file with the given checksum. The checksums apply to
the repository format, i.e. before keyword/eol transformation, and if
you were calculating checksums from working copy files the values would
be different.

One way to check repository format checksums is to use "svn info" on
working copy files. The checksum reported for one of the files modified
in r604440 should be db11617ef1454332336e00abc311d44bc698f3b3

 
>> Melissa
>
> Hi Melissa,
>
> What is the output of the 'svnadmin verify' commands which Philip
> wrote about above?

That does require server access.

Since you refer to the r604440 content does that mean you can
successfully checkout, or update to, that revision? If so that would
indicate that the revision is not corrupt in the repository.

-- 
Philip