subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: corrupt revision, "Reading one svndiff window read beyond the end of the representation"
Date Tue, 03 Aug 2010 15:17:23 GMT
Justin Georgeson wrote on Tue, Aug 03, 2010 at 10:03:21 -0500:
> 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.
> 

The script doesn't check the format of the fsfs filesystem it's opening.
Oops.

Which fsfs formats/features does fsfsverify.py not support?  (is that
documented somewhere?  I couldn't find docs about this in the script
itself.)

> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@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
> > 
> > [svnadmin@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.

Mime
View raw message