You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <da...@elego.de> on 2011/03/07 18:33:48 UTC
Reproducible checksum mismatch in 'svnadmin load'
I reproducibly run into a checksum mismatch error when dump|load'ing the
svn-org mirror on svn-qavm.apache.org.
Background: svn-qavm hosts a mirror of the public portion of svn-org.
That mirror was created by svnsync 1.6.6. I dumped it (using
svnadmin dump --deltas -q) and tried to load the dump locally, using an
r1078479 build of $svnadmin, but ran into a checksum mismatch in r75:
Reproduction:
[[[
% wget -qO- http://svn-qavm.apache.org/files/svn-org-deltas.dump > wgetted-dump
% $svnadmin create wgetted
% $svnadmin load -q wgetted < wgetted-dump
subversion/libsvn_repos/load.c:603: (apr_err=160004)
subversion/libsvn_repos/load.c:354: (apr_err=160004)
subversion/libsvn_delta/svndiff.c:782: (apr_err=160004)
subversion/libsvn_fs_fs/tree.c:2377: (apr_err=160004)
subversion/libsvn_subr/checksum.c:418: (apr_err=160004)
svnadmin: E160004: Filesystem is corrupt
subversion/libsvn_subr/checksum.c:418: (apr_err=200014)
svnadmin: E200014: Checksum mismatch while reading representation:
expected: 98d196829815a448c6add83e96bfacfd
actual: 5010ec0d2818bf780ffdcb12ef4d5bb6
zsh: exit 1 $svnadmin load -q wgetted < wgetted-dump
% $svnlook youngest wgetted
74
]]]
For comparison, a recent 1.6.x build, and an installed r1071563M build,
load the dumpfile without error. (The dumpfile goes up to r301.)
Either the month-old svnadmin is ignoring the checksum mismatch, or the
new one is falsely reporting it; which is the case?
Re: Reproducible checksum mismatch in 'svnadmin load'
Posted by Daniel Shahaf <da...@elego.de>.
Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 22:12:59 +0100:
> On 08.03.2011 21:24, Daniel Shahaf wrote:
> >Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 21:06:03 +0100:
> >>On 08.03.2011 20:58, Daniel Shahaf wrote:
> >>>Looks like r1078357 is the culprit: r1078340 loads the dump successfully
> >>>while r1078365 croaks.
> >>>
> >>>r1078357 is the merging of the integrate-txdelta-caching branch.
> >>Are you packing the repository while loading it?
> >Yep :-)
> >
> >CFLAGS=" -DSVN_FS_FS_DEFAULT_MAX_FILES_PER_DIR=4 -DPACK_AFTER_EVERY_COMMIT
> >-DSVN_DEPRECATED= -DSVN_UNALIGNED_ACCESS_IS_OK=0 -DKEEP_SUFFIX_LINES=0
> >-Wundef -Wendif-labels -Wformat=2 -Wno-format-nonliteral -Wformat-security -Wno-unreachable-code -g "
> I had a sneaking suspicion you would ;)
>
> >>What environment are you using (since I failed
> >>to reproduce it)?
> >Debian stable, 32 bit, any other details?
> >
> >>-- Stefan^2.
> >By the way: do these keys look normal? ---
> >
> >DBG: fs_fs.c:3295: get_window_key() -> ';& 73' = '0x3b26203733'
> >DBG: fs_fs.c:3295: get_window_key() -> ']� 17' = '0x5d84203137'
> >DBG: fs_fs.c:3295: get_window_key() -> ';& 73' = '0x3b26203733'
> >DBG: fs_fs.c:3295: get_window_key() -> ']� 17' = '0x5d84203137'
> >DBG: fs_fs.c:3295: get_window_key() -> 'TP 16' = '0x5450203136'
> >DBG: fs_fs.c:3295: get_window_key() -> 'TP 16' = '0x5450203136'
> >DBG: fs_fs.c:3295: get_window_key() -> '4� 15' = '0x3484203135'
> >DBG: fs_fs.c:3295: get_window_key() -> '.` 16' = '0x2e60203136'
> >DBG: fs_fs.c:3295: get_window_key() -> '.` 16' = '0x2e60203136'
> >DBG: fs_fs.c:3295: get_window_key() -> '4� 15' = '0x3484203135'
> >DBG: fs_fs.c:3295: get_window_key() -> 'E~ 16' = '0x457e203136'
> >DBG: fs_fs.c:3295: get_window_key() -> 'E~ 16' = '0x457e203136'
> >DBG: fs_fs.c:3295: get_window_key() -> '4� 15' = '0x3484203135'
> >DBG: fs_fs.c:3295: get_window_key() -> ',� 16' = '0x2c87203136'
> >DBG: fs_fs.c:3295: get_window_key() -> ',� 16' = '0x2c87203136'
> >DBG: fs_fs.c:3295: get_window_key() -> '&% 16' = '0x2625203136'
> >DBG: fs_fs.c:3295: get_window_key() -> '&% 16' = '0x2625203136'
> >DBG: fs_fs.c:3295: get_window_key() -> '4 16' = '0x34203136'
> >DBG: fs_fs.c:3295: get_window_key() -> '4� 15' = '0x3484203135'
> >
> Yes. The first part is a packed variable-length integer
> (the offset of the txdelta window within the file). The
> second part is the "relevant" part of the rev file path.
>
> But they led me to what might be the root cause of
> your problem: Try r1079544.
>
r1079544 (with r1079554) fixes the issue, both comparaed to r1078357 and
compared to r1079543.
> -- Stefan^2.
>
Thanks,
Daniel
Re: Reproducible checksum mismatch in 'svnadmin load'
Posted by Stefan Fuhrmann <st...@alice-dsl.de>.
On 08.03.2011 21:24, Daniel Shahaf wrote:
> Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 21:06:03 +0100:
>> On 08.03.2011 20:58, Daniel Shahaf wrote:
>>> Looks like r1078357 is the culprit: r1078340 loads the dump successfully
>>> while r1078365 croaks.
>>>
>>> r1078357 is the merging of the integrate-txdelta-caching branch.
>> Are you packing the repository while loading it?
> Yep :-)
>
> CFLAGS=" -DSVN_FS_FS_DEFAULT_MAX_FILES_PER_DIR=4 -DPACK_AFTER_EVERY_COMMIT
> -DSVN_DEPRECATED= -DSVN_UNALIGNED_ACCESS_IS_OK=0 -DKEEP_SUFFIX_LINES=0
> -Wundef -Wendif-labels -Wformat=2 -Wno-format-nonliteral -Wformat-security -Wno-unreachable-code -g "
I had a sneaking suspicion you would ;)
>> What environment are you using (since I failed
>> to reproduce it)?
> Debian stable, 32 bit, any other details?
>
>> -- Stefan^2.
> By the way: do these keys look normal? ---
>
> DBG: fs_fs.c:3295: get_window_key() -> ';& 73' = '0x3b26203733'
> DBG: fs_fs.c:3295: get_window_key() -> ']� 17' = '0x5d84203137'
> DBG: fs_fs.c:3295: get_window_key() -> ';& 73' = '0x3b26203733'
> DBG: fs_fs.c:3295: get_window_key() -> ']� 17' = '0x5d84203137'
> DBG: fs_fs.c:3295: get_window_key() -> 'TP 16' = '0x5450203136'
> DBG: fs_fs.c:3295: get_window_key() -> 'TP 16' = '0x5450203136'
> DBG: fs_fs.c:3295: get_window_key() -> '4� 15' = '0x3484203135'
> DBG: fs_fs.c:3295: get_window_key() -> '.` 16' = '0x2e60203136'
> DBG: fs_fs.c:3295: get_window_key() -> '.` 16' = '0x2e60203136'
> DBG: fs_fs.c:3295: get_window_key() -> '4� 15' = '0x3484203135'
> DBG: fs_fs.c:3295: get_window_key() -> 'E~ 16' = '0x457e203136'
> DBG: fs_fs.c:3295: get_window_key() -> 'E~ 16' = '0x457e203136'
> DBG: fs_fs.c:3295: get_window_key() -> '4� 15' = '0x3484203135'
> DBG: fs_fs.c:3295: get_window_key() -> ',� 16' = '0x2c87203136'
> DBG: fs_fs.c:3295: get_window_key() -> ',� 16' = '0x2c87203136'
> DBG: fs_fs.c:3295: get_window_key() -> '&% 16' = '0x2625203136'
> DBG: fs_fs.c:3295: get_window_key() -> '&% 16' = '0x2625203136'
> DBG: fs_fs.c:3295: get_window_key() -> '4 16' = '0x34203136'
> DBG: fs_fs.c:3295: get_window_key() -> '4� 15' = '0x3484203135'
>
Yes. The first part is a packed variable-length integer
(the offset of the txdelta window within the file). The
second part is the "relevant" part of the rev file path.
But they led me to what might be the root cause of
your problem: Try r1079544.
-- Stefan^2.
Re: Reproducible checksum mismatch in 'svnadmin load'
Posted by Daniel Shahaf <da...@elego.de>.
Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 21:06:03 +0100:
> On 08.03.2011 20:58, Daniel Shahaf wrote:
> >Looks like r1078357 is the culprit: r1078340 loads the dump successfully
> >while r1078365 croaks.
> >
> >r1078357 is the merging of the integrate-txdelta-caching branch.
>
> Are you packing the repository while loading it?
>
Yep :-)
CFLAGS=" -DSVN_FS_FS_DEFAULT_MAX_FILES_PER_DIR=4 -DPACK_AFTER_EVERY_COMMIT
-DSVN_DEPRECATED= -DSVN_UNALIGNED_ACCESS_IS_OK=0 -DKEEP_SUFFIX_LINES=0
-Wundef -Wendif-labels -Wformat=2 -Wno-format-nonliteral -Wformat-security -Wno-unreachable-code -g "
> What environment are you using (since I failed
> to reproduce it)?
Debian stable, 32 bit, any other details?
> -- Stefan^2.
By the way: do these keys look normal? ---
DBG: fs_fs.c:3295: get_window_key() -> ';& 73' = '0x3b26203733'
DBG: fs_fs.c:3295: get_window_key() -> ']� 17' = '0x5d84203137'
DBG: fs_fs.c:3295: get_window_key() -> ';& 73' = '0x3b26203733'
DBG: fs_fs.c:3295: get_window_key() -> ']� 17' = '0x5d84203137'
DBG: fs_fs.c:3295: get_window_key() -> 'TP 16' = '0x5450203136'
DBG: fs_fs.c:3295: get_window_key() -> 'TP 16' = '0x5450203136'
DBG: fs_fs.c:3295: get_window_key() -> '4� 15' = '0x3484203135'
DBG: fs_fs.c:3295: get_window_key() -> '.` 16' = '0x2e60203136'
DBG: fs_fs.c:3295: get_window_key() -> '.` 16' = '0x2e60203136'
DBG: fs_fs.c:3295: get_window_key() -> '4� 15' = '0x3484203135'
DBG: fs_fs.c:3295: get_window_key() -> 'E~ 16' = '0x457e203136'
DBG: fs_fs.c:3295: get_window_key() -> 'E~ 16' = '0x457e203136'
DBG: fs_fs.c:3295: get_window_key() -> '4� 15' = '0x3484203135'
DBG: fs_fs.c:3295: get_window_key() -> ',� 16' = '0x2c87203136'
DBG: fs_fs.c:3295: get_window_key() -> ',� 16' = '0x2c87203136'
DBG: fs_fs.c:3295: get_window_key() -> '&% 16' = '0x2625203136'
DBG: fs_fs.c:3295: get_window_key() -> '&% 16' = '0x2625203136'
DBG: fs_fs.c:3295: get_window_key() -> '4 16' = '0x34203136'
DBG: fs_fs.c:3295: get_window_key() -> '4� 15' = '0x3484203135'
Re: Reproducible checksum mismatch in 'svnadmin load'
Posted by Stefan Fuhrmann <st...@alice-dsl.de>.
On 08.03.2011 20:58, Daniel Shahaf wrote:
> Looks like r1078357 is the culprit: r1078340 loads the dump successfully
> while r1078365 croaks.
>
> r1078357 is the merging of the integrate-txdelta-caching branch.
Are you packing the repository while loading it?
What environment are you using (since I failed
to reproduce it)?
-- Stefan^2.
Re: Reproducible checksum mismatch in 'svnadmin load'
Posted by Daniel Shahaf <da...@elego.de>.
Looks like r1078357 is the culprit: r1078340 loads the dump successfully
while r1078365 croaks.
r1078357 is the merging of the integrate-txdelta-caching branch.
Re: Reproducible checksum mismatch in 'svnadmin load'
Posted by Daniel Shahaf <da...@elego.de>.
Daniel Shahaf wrote on Tue, Mar 08, 2011 at 21:34:48 +0200:
> Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 20:01:56 +0100:
> > On 07.03.2011 21:47, Daniel Shahaf wrote:
> > >svn-bisect says this started in r1078366.
> > >
> > Hm. I'm unable to reproduce the issue here (64 bit linux).
> > What's more bogus is that the code changed in 1078366
> > should not even get executed in your scenario.
> >
>
> I'll double-check whether that revnum is the correct one.
It's not. (The checksum failure reproduces with r1078365.) Sorry.
I'll dig further.
Re: Reproducible checksum mismatch in 'svnadmin load'
Posted by Daniel Shahaf <da...@elego.de>.
Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 20:01:56 +0100:
> On 07.03.2011 21:47, Daniel Shahaf wrote:
> >svn-bisect says this started in r1078366.
> >
> Hm. I'm unable to reproduce the issue here (64 bit linux).
> What's more bogus is that the code changed in 1078366
> should not even get executed in your scenario.
>
I'll double-check whether that revnum is the correct one.
> Can you try the following patch:
>
> Index: subversion/libsvn_subr/cache-inprocess.c
> ===================================================================
> --- subversion/libsvn_subr/cache-inprocess.c (revision 1079481)
> +++ subversion/libsvn_subr/cache-inprocess.c (working copy)
> @@ -462,6 +462,7 @@
> move_page_to_front(cache, entry->page);
>
> *found = TRUE;
> + SVN_ERR_MALFUNCTION_NO_RETURN();
> err = func(value_p, entry->value, entry->size, baton, pool);
> return unlock_cache(cache, err);
> }
>
> This code should only get executed if you start svnadmin
> with an -M0 parameter.
>
Trying r1078479 with that patch doesn't trigger the assert.
> -- Stefan^2.
>
> >Daniel Shahaf wrote on Mon, Mar 07, 2011 at 19:33:48 +0200:
> >>I reproducibly run into a checksum mismatch error when dump|load'ing the
> >>svn-org mirror on svn-qavm.apache.org.
> >>
> >>Background: svn-qavm hosts a mirror of the public portion of svn-org.
> >>That mirror was created by svnsync 1.6.6. I dumped it (using
> >>svnadmin dump --deltas -q) and tried to load the dump locally, using an
> >>r1078479 build of $svnadmin, but ran into a checksum mismatch in r75:
> >>
> >>Reproduction:
> >>[[[
> >>% wget -qO- http://svn-qavm.apache.org/files/svn-org-deltas.dump> wgetted-dump
> >>% $svnadmin create wgetted
> >>% $svnadmin load -q wgetted< wgetted-dump
> >>subversion/libsvn_repos/load.c:603: (apr_err=160004)
> >>subversion/libsvn_repos/load.c:354: (apr_err=160004)
> >>subversion/libsvn_delta/svndiff.c:782: (apr_err=160004)
> >>subversion/libsvn_fs_fs/tree.c:2377: (apr_err=160004)
> >>subversion/libsvn_subr/checksum.c:418: (apr_err=160004)
> >>svnadmin: E160004: Filesystem is corrupt
> >>subversion/libsvn_subr/checksum.c:418: (apr_err=200014)
> >>svnadmin: E200014: Checksum mismatch while reading representation:
> >> expected: 98d196829815a448c6add83e96bfacfd
> >> actual: 5010ec0d2818bf780ffdcb12ef4d5bb6
> >>
> >>zsh: exit 1 $svnadmin load -q wgetted< wgetted-dump
> >>% $svnlook youngest wgetted
> >>74
> >>]]]
> >>
> >>For comparison, a recent 1.6.x build, and an installed r1071563M build,
> >>load the dumpfile without error. (The dumpfile goes up to r301.)
> >>
> >>Either the month-old svnadmin is ignoring the checksum mismatch, or the
> >>new one is falsely reporting it; which is the case?
> >>[[[
> >>% $svn log -vr75:74 http://svn-qavm.apache.org/repos/svn-org/
> >>------------------------------------------------------------------------
> >>r75 | kfogel | 2007-04-13 09:16:37 +0300 (Fri, 13 Apr 2007) | 16 lines
> >>Changed paths:
> >> D /trunk/documents/meeting-minutes
> >> A /trunk/documents/meetings (from /trunk/documents/meeting-minutes:73)
> >> R /trunk/documents/meetings/2006-10-05-board-meeting.txt (from /trunk/documents/meeting-minutes/2006-10-05-board-meeting.txt:74)
> >> R /trunk/documents/meetings/2007-03-12-board-meeting.txt (from /trunk/documents/meeting-minutes/2007-03-12-board-meeting.txt:74)
> >> R /trunk/documents/meetings/2007-03-17-board-meeting.txt (from /trunk/documents/meeting-minutes/2007-03-17-board-meeting.txt:74)
> >> R /trunk/documents/meetings/2007-03-17-members-meeting.txt (from /trunk/documents/meeting-minutes/2007-03-17-members-meeting.txt:74)
> >> R /trunk/documents/meetings/board-meeting-template.txt (from /trunk/documents/meeting-minutes/board-meeting-template.txt:74)
> >> R /trunk/documents/meetings/members-meeting-template.txt (from /trunk/documents/meeting-minutes/members-meeting-template.txt:74)
> >>
> >>Use the same templates for meeting agendas as well as for minutes.
> >>
> >>* documents/meeting-minutes/: Renamed to...
> >>
> >>* documents/meetings/: ...here.
> >>
> >>* documents/meetings/board-meeting-template.txt,
> >> documents/meetings/members-meeting-template.txt: Add section for
> >> agenda as well as minutes.
> >>
> >>* documents/meetings/2006-10-05-board-meeting.txt
> >> documents/meetings/2007-03-12-board-meeting.txt
> >> documents/meetings/2007-03-17-board-meeting.txt
> >> documents/meetings/2007-03-17-members-meeting.txt: Add note that
> >> these were written before the new format.
> >>
> >>------------------------------------------------------------------------
> >>r74 | kfogel | 2007-04-13 09:07:47 +0300 (Fri, 13 Apr 2007) | 3 lines
> >>Changed paths:
> >> M /trunk/documents/corporate-cla.txt
> >> M /trunk/documents/individual-cla.txt
> >>
> >>* documents/individual-cla.txt
> >> documents/corporate-cla.txt: Add a question about GPG-signing.
> >>
> >>------------------------------------------------------------------------
> >>]]]
> >
>
Re: Reproducible checksum mismatch in 'svnadmin load'
Posted by Stefan Fuhrmann <eq...@web.de>.
On 07.03.2011 21:47, Daniel Shahaf wrote:
> svn-bisect says this started in r1078366.
>
Hm. I'm unable to reproduce the issue here (64 bit linux).
What's more bogus is that the code changed in 1078366
should not even get executed in your scenario.
Can you try the following patch:
Index: subversion/libsvn_subr/cache-inprocess.c
===================================================================
--- subversion/libsvn_subr/cache-inprocess.c (revision 1079481)
+++ subversion/libsvn_subr/cache-inprocess.c (working copy)
@@ -462,6 +462,7 @@
move_page_to_front(cache, entry->page);
*found = TRUE;
+ SVN_ERR_MALFUNCTION_NO_RETURN();
err = func(value_p, entry->value, entry->size, baton, pool);
return unlock_cache(cache, err);
}
This code should only get executed if you start svnadmin
with an -M0 parameter.
-- Stefan^2.
> Daniel Shahaf wrote on Mon, Mar 07, 2011 at 19:33:48 +0200:
>> I reproducibly run into a checksum mismatch error when dump|load'ing the
>> svn-org mirror on svn-qavm.apache.org.
>>
>> Background: svn-qavm hosts a mirror of the public portion of svn-org.
>> That mirror was created by svnsync 1.6.6. I dumped it (using
>> svnadmin dump --deltas -q) and tried to load the dump locally, using an
>> r1078479 build of $svnadmin, but ran into a checksum mismatch in r75:
>>
>> Reproduction:
>> [[[
>> % wget -qO- http://svn-qavm.apache.org/files/svn-org-deltas.dump> wgetted-dump
>> % $svnadmin create wgetted
>> % $svnadmin load -q wgetted< wgetted-dump
>> subversion/libsvn_repos/load.c:603: (apr_err=160004)
>> subversion/libsvn_repos/load.c:354: (apr_err=160004)
>> subversion/libsvn_delta/svndiff.c:782: (apr_err=160004)
>> subversion/libsvn_fs_fs/tree.c:2377: (apr_err=160004)
>> subversion/libsvn_subr/checksum.c:418: (apr_err=160004)
>> svnadmin: E160004: Filesystem is corrupt
>> subversion/libsvn_subr/checksum.c:418: (apr_err=200014)
>> svnadmin: E200014: Checksum mismatch while reading representation:
>> expected: 98d196829815a448c6add83e96bfacfd
>> actual: 5010ec0d2818bf780ffdcb12ef4d5bb6
>>
>> zsh: exit 1 $svnadmin load -q wgetted< wgetted-dump
>> % $svnlook youngest wgetted
>> 74
>> ]]]
>>
>> For comparison, a recent 1.6.x build, and an installed r1071563M build,
>> load the dumpfile without error. (The dumpfile goes up to r301.)
>>
>> Either the month-old svnadmin is ignoring the checksum mismatch, or the
>> new one is falsely reporting it; which is the case?
>> [[[
>> % $svn log -vr75:74 http://svn-qavm.apache.org/repos/svn-org/
>> ------------------------------------------------------------------------
>> r75 | kfogel | 2007-04-13 09:16:37 +0300 (Fri, 13 Apr 2007) | 16 lines
>> Changed paths:
>> D /trunk/documents/meeting-minutes
>> A /trunk/documents/meetings (from /trunk/documents/meeting-minutes:73)
>> R /trunk/documents/meetings/2006-10-05-board-meeting.txt (from /trunk/documents/meeting-minutes/2006-10-05-board-meeting.txt:74)
>> R /trunk/documents/meetings/2007-03-12-board-meeting.txt (from /trunk/documents/meeting-minutes/2007-03-12-board-meeting.txt:74)
>> R /trunk/documents/meetings/2007-03-17-board-meeting.txt (from /trunk/documents/meeting-minutes/2007-03-17-board-meeting.txt:74)
>> R /trunk/documents/meetings/2007-03-17-members-meeting.txt (from /trunk/documents/meeting-minutes/2007-03-17-members-meeting.txt:74)
>> R /trunk/documents/meetings/board-meeting-template.txt (from /trunk/documents/meeting-minutes/board-meeting-template.txt:74)
>> R /trunk/documents/meetings/members-meeting-template.txt (from /trunk/documents/meeting-minutes/members-meeting-template.txt:74)
>>
>> Use the same templates for meeting agendas as well as for minutes.
>>
>> * documents/meeting-minutes/: Renamed to...
>>
>> * documents/meetings/: ...here.
>>
>> * documents/meetings/board-meeting-template.txt,
>> documents/meetings/members-meeting-template.txt: Add section for
>> agenda as well as minutes.
>>
>> * documents/meetings/2006-10-05-board-meeting.txt
>> documents/meetings/2007-03-12-board-meeting.txt
>> documents/meetings/2007-03-17-board-meeting.txt
>> documents/meetings/2007-03-17-members-meeting.txt: Add note that
>> these were written before the new format.
>>
>> ------------------------------------------------------------------------
>> r74 | kfogel | 2007-04-13 09:07:47 +0300 (Fri, 13 Apr 2007) | 3 lines
>> Changed paths:
>> M /trunk/documents/corporate-cla.txt
>> M /trunk/documents/individual-cla.txt
>>
>> * documents/individual-cla.txt
>> documents/corporate-cla.txt: Add a question about GPG-signing.
>>
>> ------------------------------------------------------------------------
>> ]]]
>
Re: Reproducible checksum mismatch in 'svnadmin load'
Posted by Daniel Shahaf <da...@elego.de>.
svn-bisect says this started in r1078366.
Daniel Shahaf wrote on Mon, Mar 07, 2011 at 19:33:48 +0200:
> I reproducibly run into a checksum mismatch error when dump|load'ing the
> svn-org mirror on svn-qavm.apache.org.
>
> Background: svn-qavm hosts a mirror of the public portion of svn-org.
> That mirror was created by svnsync 1.6.6. I dumped it (using
> svnadmin dump --deltas -q) and tried to load the dump locally, using an
> r1078479 build of $svnadmin, but ran into a checksum mismatch in r75:
>
> Reproduction:
> [[[
> % wget -qO- http://svn-qavm.apache.org/files/svn-org-deltas.dump > wgetted-dump
> % $svnadmin create wgetted
> % $svnadmin load -q wgetted < wgetted-dump
> subversion/libsvn_repos/load.c:603: (apr_err=160004)
> subversion/libsvn_repos/load.c:354: (apr_err=160004)
> subversion/libsvn_delta/svndiff.c:782: (apr_err=160004)
> subversion/libsvn_fs_fs/tree.c:2377: (apr_err=160004)
> subversion/libsvn_subr/checksum.c:418: (apr_err=160004)
> svnadmin: E160004: Filesystem is corrupt
> subversion/libsvn_subr/checksum.c:418: (apr_err=200014)
> svnadmin: E200014: Checksum mismatch while reading representation:
> expected: 98d196829815a448c6add83e96bfacfd
> actual: 5010ec0d2818bf780ffdcb12ef4d5bb6
>
> zsh: exit 1 $svnadmin load -q wgetted < wgetted-dump
> % $svnlook youngest wgetted
> 74
> ]]]
>
> For comparison, a recent 1.6.x build, and an installed r1071563M build,
> load the dumpfile without error. (The dumpfile goes up to r301.)
>
> Either the month-old svnadmin is ignoring the checksum mismatch, or the
> new one is falsely reporting it; which is the case?
> [[[
> % $svn log -vr75:74 http://svn-qavm.apache.org/repos/svn-org/
> ------------------------------------------------------------------------
> r75 | kfogel | 2007-04-13 09:16:37 +0300 (Fri, 13 Apr 2007) | 16 lines
> Changed paths:
> D /trunk/documents/meeting-minutes
> A /trunk/documents/meetings (from /trunk/documents/meeting-minutes:73)
> R /trunk/documents/meetings/2006-10-05-board-meeting.txt (from /trunk/documents/meeting-minutes/2006-10-05-board-meeting.txt:74)
> R /trunk/documents/meetings/2007-03-12-board-meeting.txt (from /trunk/documents/meeting-minutes/2007-03-12-board-meeting.txt:74)
> R /trunk/documents/meetings/2007-03-17-board-meeting.txt (from /trunk/documents/meeting-minutes/2007-03-17-board-meeting.txt:74)
> R /trunk/documents/meetings/2007-03-17-members-meeting.txt (from /trunk/documents/meeting-minutes/2007-03-17-members-meeting.txt:74)
> R /trunk/documents/meetings/board-meeting-template.txt (from /trunk/documents/meeting-minutes/board-meeting-template.txt:74)
> R /trunk/documents/meetings/members-meeting-template.txt (from /trunk/documents/meeting-minutes/members-meeting-template.txt:74)
>
> Use the same templates for meeting agendas as well as for minutes.
>
> * documents/meeting-minutes/: Renamed to...
>
> * documents/meetings/: ...here.
>
> * documents/meetings/board-meeting-template.txt,
> documents/meetings/members-meeting-template.txt: Add section for
> agenda as well as minutes.
>
> * documents/meetings/2006-10-05-board-meeting.txt
> documents/meetings/2007-03-12-board-meeting.txt
> documents/meetings/2007-03-17-board-meeting.txt
> documents/meetings/2007-03-17-members-meeting.txt: Add note that
> these were written before the new format.
>
> ------------------------------------------------------------------------
> r74 | kfogel | 2007-04-13 09:07:47 +0300 (Fri, 13 Apr 2007) | 3 lines
> Changed paths:
> M /trunk/documents/corporate-cla.txt
> M /trunk/documents/individual-cla.txt
>
> * documents/individual-cla.txt
> documents/corporate-cla.txt: Add a question about GPG-signing.
>
> ------------------------------------------------------------------------
> ]]]