On Wed, Jan 31, 2018 at 4:12 PM, Santosh Kondapuram
<skondapu...@vitechinc.com> wrote:
> Hi Johan,
>
> 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 !!!
>
> FYI,
>
> 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.
Okay, thanks for re-testing that.
What to do next? I think it depends on whether or not this is a real
collision, or why the collision-detection code went wrong. Normally
you can catchup with the original repo by creating another incremental
dump of the remaining revisions, and loading that into the new
repository. You can re-enable rep-sharing before doing so, so the
additional revisions are using the rep-sharing functionality.
However, I'm still wondering what went wrong here. If there is a real
sha1 collision, you won't be able to checkout a working copy which
contains both colliding files (though it's certainly possible that
both files would normally not appear together in a working copy --
perhaps the "first file" is already long deleted, so it's only part of
ancient history in your repository).
To find out a little bit more about the (alleged) collision, can you
do the following, by using the sqlite3 executable (perhaps it's
installed standard on your system)?
go to the db subdir of your repository
sqlite3 rep-cache.db "select * from rep_cache where
hash='9db457be74545c184242e57208bf1d56db1f15b2'"
I think you'll get back at least two rows. The schema of the table is:
( hash TEXT NOT NULL PRIMARY KEY, revision INTEGER NOT NULL, offset
INTEGER NOT NULL, size INTEGER NOT NULL, expanded_size INTEGER NOT
NULL )
The revision columns that you get back might be interesting for
further investigation (perhaps by looking at them in the original
repo). Maybe you can 'svn log -v' those revisions, and run 'svn cat
URL_OF_FILE@REV' for each of the affected files (and the corresponding
revisions) to see their contents (and perhaps sha1sum them with a
commandline tool).
--
Johan
