On Tue, Apr 18, 2017 at 12:54:20AM +0000, Daniel Shahaf wrote:
> % svnadmin load r2 < dump 
> <<< Started new transaction, based on original revision 1
>      * editing path : shattered-1.pdf ... done.
>      * editing path : shattered-2.pdf ...svnadmin: E200014: Checksum mismatch 
> for '/shattered-2.pdf':
>    expected:  5bd9d8cabc46041579a311230539b8d1
>      actual:  ee4aa52b139d925f8d8884402b0a750c
> 
> zsh: exit 1     svnadmin load r2 < dump
> % 
> ]]]
> 
> That's with 1.9.5.  Is it fixed on trunk now?  I'm not sure whether
> r1785754 addresses that.

Yes, this is fixed on trunk :-)

<<< Started new transaction, based on original revision 3
     * editing path : trunk/shattered-1.pdf ... done.
svnadmin: warning: apr_err=SVN_ERR_FS_AMBIUGOUS_CHECKSUM_REP
svnadmin: warning: W160067: SHA1 of reps '-1 3 381130 422435 
5bd9d8cabc46041579a311230539b8d1 38762cf7f55934b34d179ae6a4c80cadccbb7f0a 
2-2/_5' and '-1 0 381130 
422435 5bd9d8cabc46041579a311230539b8d1 
38762cf7f55934b34d179ae6a4c80cadccbb7f0a 2-2/_5' matches 
(38762cf7f55934b34d179ae6a4c80cadccbb7f0a) but contents differ
     * editing path : trunk/shattered-2.pdf ... done.

------- Committed revision 3 >>>

Of course, the working copy and RA protocols are still broken.
Editing both files and attempting a commit results in an error:

Sending        shattered-1.pdf
Sending        shattered-2.pdf
Transmitting file data ..subversion/svn/commit-cmd.c:185,
subversion/libsvn_client/commit.c:992,
subversion/libsvn_client/commit.c:156: (apr_err=SVN_ERR_CHECKSUM_MISMATCH)
svn: E200014: Commit failed (details follow):
subversion/libsvn_client/commit.c:904,
subversion/libsvn_client/commit_util.c:1933,
subversion/libsvn_wc/adm_crawler.c:1105,
subversion/libsvn_repos/commit.c:585,
subversion/libsvn_fs/fs-loader.c:1595,
subversion/libsvn_fs_fs/tree.c:3060,
subversion/libsvn_subr/checksum.c:658: (apr_err=SVN_ERR_CHECKSUM_MISMATCH)
svn: E200014: Base checksum mismatch on '/trunk/shattered-2.pdf':
   expected:  ee4aa52b139d925f8d8884402b0a750c
     actual:  5bd9d8cabc46041579a311230539b8d1

I suppose that is acceptable for now. The repository's health has priority.

Reply via email to