As you suggested I have removed the leading spaces from line 39 (enable-rep-sharing=false) and this time it worked and was able to successfully load the problematic revision.
So does this conclude I have the sha-1 colliding files in my repo ? Also what are the next steps to catchup the latest revisions from the master node ?
Appreciate all your help and great working with you on this issue !!!
By the way I have tried running the following command " svnadmin load -M 0 /u01/svn/repos < incdump724413.txt "with rep-sharing enabled and still see the same issue. I have tried doing this before the above work around which worked.
From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
Sent: Wednesday, January 31, 2018 8:59 AM
To: Santosh Kondapuram <SKondapuram_at_vitechinc.com>
Subject: Re: Issue while loading the SVN Dump SVN version 1.9.7
On Wed, Jan 31, 2018 at 2:44 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Wed, Jan 31, 2018 at 9:28 AM, Santosh Kondapuram
> <SKondapuram_at_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.
>> [root_at_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.
Can you double-check that using -M 0 for the 'svnadmin load' operation doesn't solve the problem (while keeping rep-sharing enabled)?
svnadmin load -M 0 /u01/svn/repos < incdump724413.txt
It's just that this works around the only currently known bug in the sha1-collision-detection code, so I want to be really sure that this workaround doesn't help in your case and we need to look further.
This e-mail message and any files transmitted with it may contain confidential and proprietary information and are intended solely for the use of the individual or entity to which they are addressed. Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you have received this e-mail in error please notify the sender by reply email and destroy all copies of the original message. Thank you for your cooperation.
Received on 2018-01-31 16:13:12 CET