I would get more advice from people here before you invest that time. I'm a relative amateur and would listen to people with more experience than myself.
--Matt On Thu, Feb 22, 2018 at 2:29 PM, Myria <myriac...@gmail.com> wrote: > That was one document we ran into when searching, yes. > > We can do an svnsync, but this will take about a week to run--the > repository is 43 GB with 600,000 commits. I guess we'll start it now. > > On Thu, Feb 22, 2018 at 2:04 PM, Matt Simmons <band...@gmail.com> wrote: > > Hi Melissa, > > > > That definitely is interesting. > > > > I assume you have read > > http://blogs.collab.net/subversion/subversion-sha1- > collision-problem-statement-prevention-remediation-options > > > > If you do an svnsync to another location and attempt the commit there, > does > > the problem replicate itself? > > > > --Matt > > > > > > On Thu, Feb 22, 2018 at 12:30 PM, Myria <myriac...@gmail.com> 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? This file is a binary pixel shader compiled from > >> a build process. It's most certainly not Google's SHA-1 collision PDF > >> files. We also scanned the repository to confirm that nobody has > >> committed Google's collision files. > >> > >> Occam's Razor suggests that something is wrong with our repository or > >> Subversion itself, rather than this being a true SHA-1 collision. In > >> that case, what is wrong with our repository? > >> > >> If this really is a SHA-1 collision, it would be major cryptography > >> news that someone randomly ran into a second collision without even > >> trying. In that case, is there a method by which we could recover the > >> two files that supposedly have the same SHA-1? The collision doesn't > >> appear to be in the file itself, but in some sort of diff or revision > >> output? > >> > >> Thanks, > >> > >> Melissa > > > > > > > > > > -- > > "Today, vegetables... Tomorrow, the world!" > -- "Today, vegetables... Tomorrow, the world!"
