On Fri, Feb 23, 2018 at 01:06:36PM -0800, Myria wrote: > I'm not subscribed to this mailing list, so I have no standard way to > reply to Philip's email. I don't even know his email address. > > > 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. > > 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. > > 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. > > 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? > > Melissa
Hi Melissa, What is the output of the 'svnadmin verify' commands which Philip wrote about above? I think the cause of the problem is still unclear, and we probably won't find a good answer without more information such as this. Stefan
