RE: corrupt revision, "Reading one svndiff window read beyond the end of the representation"

Think I have it fixed now. In case this is helpful to anyone else, here's the final set of diffs from the original corrupt rev file and the now working copy.

Thanks for the help!

[svnadmin_at_hourdcm1 ~]$ diff cm3-39245 39245
20c20
< text: 39008 0 820 34402 b0823a9c03c803b37b5adc33430cc796 f310eb9358578507ca831265f855ba972af6ca23 39244-uc7/_9

---
> text: 39014 0 820 34402 b0823a9c03c803b37b5adc33430cc796 f310eb9358578507ca831265f855ba972af6ca23 39244-ua4/_9
441c441
< dir 7-29081.0-38388.r38584/540
---
> dir 6-29081.0-38388.r38584/540
1028c1028
< text: 39245 2144 10888 10888 789605216a8f727194ed4fde84f17a12
---
> text: 39245 2144 10888 10888 67364687e6d64ee34f5d21aa9ab3d76c
1242c1242
< dir 5-24766.0.r38038/4016
---
> dir 4-24766.0.r38038/4016
1273c1273
< text: 39245 15409 654 654 6eca19e967a74255e570ca8b067af7c8
---
> text: 39245 15409 654 654 236f0e0057d1777e4bffe306c9753b77
1544c1544
< pred: 0.0.r39244/52342
---
> pred: 0.0.r39244/52346
1551c1551
< e-17515.0-38388.t39244-uc7 modify-file true true /branches/branch_5000_0_2_0/port/com/lgc/prowess/tool/input/SmartInputProc.java
---
> e-17515.0-38388.t39244-ua4 modify-file true true /branches/branch_5000_0_2_0/port/com/lgc/prowess/tool/input/SmartInputProc.java
-----Original Message-----
From: Justin Georgeson 
Sent: Tuesday, August 03, 2010 2:26 PM
To: Justin Georgeson
Cc: users_at_subversion.apache.org
Subject: RE: corrupt revision, "Reading one svndiff window read beyond the end of the representation"
After a series of changing the node-revision and checksum errors I now have a revision file in the backup repo that I verifies and I can checkout head of that branch and do a diff on that revision. However, I can't do a log on that revision yet
[svnadmin_at_hourdcm1 input]$ svn log -r 39245
svn: Corrupt node-revision '8g-3.0-38388.r38555/8238'
svn: Found malformed header in revision file
I'm going to save a copy of the current rev file and keep on plugging away at these node-revision/checksum errors and hopefully end up with a fully working rev file.
-----Original Message-----
From: Justin Georgeson [mailto:JGeorgeson_at_lgc.com] 
Sent: Tuesday, August 03, 2010 1:37 PM
To: Daniel Shahaf
Cc: users_at_subversion.apache.org
Subject: RE: corrupt revision, "Reading one svndiff window read beyond the end of the representation"
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.
[svnadmin_at_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.
[svnadmin_at_hourdcm1 /tmp]$ svnadmin verify -r 39245 /u1/repos/prowess
svnadmin: Checksum mismatch while reading representation:
   expected:  2acda48d7b91e8f07aff6270fdcb9e7b
     actual:  7d22c19004b23609f3a460fb9adbed96
[svnadmin_at_hourdcm1 /tmp]$ grep 2acda48d7b91e8f07aff6270fdcb9e7b /u1/repos/prowess/db/revs/39/39245
text: 39245 605 1191 1191 2acda48d7b91e8f07aff6270fdcb9e7b
[svnadmin_at_hourdcm1 /tmp]$ grep 7d22c19004b23609f3a460fb9adbed96 /u1/repos/prowess/db/revs/39/39245
[svnadmin_at_hourdcm1 /tmp]$  
-----Original Message-----
From: Justin Georgeson 
Sent: Tuesday, August 03, 2010 10:03 AM
To: 'Daniel Shahaf'
Cc: users_at_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.s_at_daniel.shahaf.name] 
Sent: Tuesday, August 03, 2010 9:30 AM
To: Justin Georgeson
Cc: users_at_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
> 
> [svnadmin_at_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.