On Wed, Jan 31, 2018 at 9:28 AM, Santosh Kondapuram <skondapu...@vitechinc.com> wrote: > Hi Johan, > > Sorry for the delayed response as I was in long vacation. > Yes, I don’t think we are hitting the real sha-1 collision in our repository > and as you said it might be another bug in the sha-1 collision detection code. > I am sure that no one committed the sha-1-colliding files from > https://shattered.io > Our repository is very huge with 1 Million + revisions and I am seeing the > issue only while loading the specific revision 724413. I am able to load the > revisions before and after it. > As you suggested I have now loaded the dump till 724412 which is the revision > before the problematic one with rep sharing enabled. > It's not allowing me to load the problematic revision with rep-sharing > disabled and getting below message. > > FYI, > > [root@vitech-svn-slave-test-01 svndump]# svnadmin load /u01/svn/repos < > incdump724413.txt > svnadmin: E200002: Error while parsing config file: > /u01/svn/repos/db/fsfs.conf: > svnadmin: E200002: line 39: Option expected
Hm, that indicates that there was a syntax error on line 39 in the db/fsfs.conf file you edited (when you were trying to disable rep-sharing). Can you take another look and try again with rep-sharing disabled? That line in fsfs.conf should be (without leading spaces): enable-rep-sharing = false Now, I'm not sure what we'll be able to do next to figure this out. First step is probably find out which two files are colliding, and what their contents is exactly. It's extremely unlikely that there is a real sha1 collision, but we have to rule it out I suppose. -- Johan
