The new test repo up to r39244 was created and the merge was successfully
committed. Checking the rev file in that new repo it looks ok. But when I put
the new rev file into an existing repo it is still corrupt, although for
different reasons now. I tried fsfsverify.py on this new rev file just in case,
same error.
[svnad...@hourdcm1 /tmp]$ svnadmin verify -r 39245 /u1/repos/prowess
svnadmin: Corrupt node-revision 'g-17515.0-38388.r38555/6646'
svnadmin: Found malformed header in revision file
That string comes from this entry
K 19
SmartInputTool.java
V 32
file g-17515.0-38388.r38555/6646
Which is the entry just prior to the entry for the file that was modified in
this merge. If I change the entry to match that of the original rev file then
(change the trailing /6646 to /6649) then the verify fails with a checksum
mismatch. Interestingly I don't see the 'actual' checksum anywhere in the file,
but I do see the expected.
[svnad...@hourdcm1 /tmp]$ svnadmin verify -r 39245 /u1/repos/prowess
svnadmin: Checksum mismatch while reading representation:
expected: 2acda48d7b91e8f07aff6270fdcb9e7b
actual: 7d22c19004b23609f3a460fb9adbed96
[svnad...@hourdcm1 /tmp]$ grep 2acda48d7b91e8f07aff6270fdcb9e7b
/u1/repos/prowess/db/revs/39/39245
text: 39245 605 1191 1191 2acda48d7b91e8f07aff6270fdcb9e7b
[svnad...@hourdcm1 /tmp]$ grep 7d22c19004b23609f3a460fb9adbed96
/u1/repos/prowess/db/revs/39/39245
[svnad...@hourdcm1 /tmp]$
-----Original Message-----
From: Justin Georgeson
Sent: Tuesday, August 03, 2010 10:03 AM
To: 'Daniel Shahaf'
Cc: users@subversion.apache.org
Subject: RE: corrupt revision, "Reading one svndiff window read beyond the end
of the representation"
Regarding reproducibility, that's what I was going for with #3. I found another
thread, http://svn.haxx.se/users/archive-2009-06/0723.shtml, concluding this
error is due to fsfsverify not being current with the latest format, so I'll
give the svndump to new repo and redo revision in new repo a try.
-----Original Message-----
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
Sent: Tuesday, August 03, 2010 9:30 AM
To: Justin Georgeson
Cc: users@subversion.apache.org
Subject: Re: corrupt revision, "Reading one svndiff window read beyond the end
of the representation"
Justin Georgeson wrote on Mon, Aug 02, 2010 at 17:39:49 -0500:
> I have a repo with >39k revisions. Last week, r39245 was committed, a merge
> of a single file from trunk to branch. It is the HEAD revision of that file
> on that branch. Turns out this revision is corrupt
>
> [svnad...@hourdcm3 ~]$ svnadmin verify -r 39245 /repos/prowess
> svnadmin: Reading one svndiff window read beyond the end of the representation
>
Is this reproducible? i.e., if you re-commit r39245 (on top of, say, an
svnsync/backup repository at r39244), does it become corrupted again?
> I've searched from r30000 to HEAD in this repo and that's the only rev that
> fails the verify. All our backup copies have the same issue too. I'm
> wondering what our options for recovery are. Some suggestions we have come up
> with internally are:
>
> 1. Developer still has sandbox which reports the parent folder as updated, so
> have him 'svn cat' the previous version and commit that, then re-commit the
> changes from the corrupt revision
> 2. 'svn rm' the file from the server and re-add it (losing ancestry)
> 3. Some combination of svndump up to that revision, import to new repo, redo
> that merge in new repo, overwrite the revision file with new one
> 4. delete revision file (seems like bad idea)
> 5. svn dump up to corrupt revision and everything after bad revision, merge
> dumps, create new repo, redo merge
>
Don't do #4.
#5 sounds reasonable. You have to restitch history in some way now.
> Is there something else we missed? Which of these seems like the
> safest/easiest?
>
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient. Any
> review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
