Justin Georgeson wrote on Tue, Aug 03, 2010 at 13:37:22 -0500: > 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 >
This is part of the representation of the directory node which contains SmartInputTool.java. > 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. > The 6646|6649 is a byte offset into the revision file revs/38/38555. Presumably only one of the two offsets is correct here... > [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 This tells you that if you seek to the 605th byte of revs/39/39245, you'll find a representation of length 1191 bytes (after stripping "DELTA"/"PLAIN" headers and "ENDREP" trailers) to create a file of length 1191 bytes. The file which the representation expands to shall have an md5 checksum of 2acda48d7b91e8f07aff6270fdcb9e7b. > [svnad...@hourdcm1 /tmp]$ grep 7d22c19004b23609f3a460fb9adbed96 > /u1/repos/prowess/db/revs/39/39245 > [svnad...@hourdcm1 /tmp]$ > Well, now you know what these numbers mean. HTH; I have to sleep now, so I'll check back on this thread tomorrow evening. > -----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.
