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.
