subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Engel <>
Subject Checksum mismatch bug in 1.8.18
Date Fri, 28 Jul 2017 22:00:40 GMT

I think I'm running into a bug in svnadmin in the latest 1.8 release (1.8.18).  It is not
present in 1.8.17 nor 1.9.5 nor 1.9.6.  I'm guessing it's related to the recent changes around
strict repsharing.  I'm not subscribed to the mailing list, so please CC me on any responses.

Here are the relevant details:

OS: Windows 10 and Windows 2012 R2
Subversion release: 1.8.18
Both SlikSVN release:
svnadmin, version 1.8.18-SlikSvn-1.8.18-X64 (SlikSvn/1.8.18) X64
   compiled Jul 17 2017, 13:03:37 on x86_64-microsoft-windows6.2.9200
And Collabnet release:
svnadmin, version 1.8.18 (r1800620)
   compiled Jul  7 2017, 05:51:59 on x86_64-microsoft-windows6.2.9200

Performing an svnadmin load results in the following error:
<<< Started new transaction, based on original revision 650
     * editing path : Dev/Common/Utils/External/StampVerData/MetaBuilderVersion.inf ... done.
     * editing path : Dev/Common/Utils/External/StampVerData/MetaBuilderVersionDBG.inf ...
     * editing path : Dev/Common/Utils/External/StampVerData/OracleVersion.inf ...svnadmin:
E160000: SHA1 of reps '-1 0 45 132 a6ea37d29094deece56250ebe167ce46 6a2d6bc4c7e58c0d2627a1b0dd5b23e542aec4d1
650-i2/_8' and '-1 136 45 132 a6ea37d29094deece56250ebe167ce46 6a2d6bc4c7e58c0d2627a1b0dd5b23e542aec4d1
650-i2/_8' matches (6a2d6bc4c7e58c0d2627a1b0dd5b23e542aec4d1) but contents differ
svnadmin: E160004: Filesystem is corrupt
svnadmin: E200014: Checksum mismatch while reading representation:
   expected:  a6ea37d29094deece56250ebe167ce46
     actual:  5f696f5d0755f3bcb5e927bdfba4bfa8

In order to reproduce the error, you can use the attached VersionStamps3 repository dump file.
 It was taken with the same version of svnadmin from a multi-GB repository that's been around
for over a decade and pruned (svndumpfilter) to a small set of files and revisions in one
folder while still encountering the error.  I first encountered the error another place very
quickly in an incremental load on top of a repo that was loaded from 1.8.14, but that one
was on a revision north of 120,000+.  This is way easier to reproduce.  I tried filtering
the dump further and dropping empty revisions, but the error did not occur in those cases.
 The error also did not occur using 1.8.17, 1.9.5., and 1.9.6.  It also did not occur in 1.8.18
if I set enable-rep-sharing = false before performing the load.

Repro.bat script:
@echo off

rem You might need to adjust these lines to point to your
rem compiled-from-source Subversion binaries, if using those:
for %%i in (svn.exe) do set SVN="%%~$PATH:i"
for %%i in (svnadmin.exe) do set SVNADMIN="%%~$PATH:i"

rem Only supported access method: file://. If http:// or svn://, then
rem you'll have to configure it yourself first.
set URL=file:///%CD%/repos
set URL=%URL:\=/%
echo Base url for repo: %URL%

if exist repos rmdir /s /q repos
if exist import-me rmdir /s /q import-me
if exist wc rmdir /s /q wc
%SVNADMIN% create repos

echo Making a Tree for import...
mkdir import-me\Dev\Common\Utils\External
echo Importing it...
cd import-me
%SVN% import -q -m "Initial import." %URL%
cd ..

rem This is where your reproduction recipe goes.
svnadmin --version
svnadmin load repos < VersionStamps3
goto :eof


View raw message