Stefan Sperling <s...@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