From users-return-4070-daniel=haxx.se@subversion.apache.org Tue Aug 3 00:48:07 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on giant.haxx.se X-Spam-Level: X-Spam-Status: No, score=0.5 required=3.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,MIME_QP_LONG_LINE,T_DKIM_INVALID,T_RP_MATCHES_RCVD autolearn=no version=3.3.1 Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with SMTP id o72Mm6hR015119 for ; Tue, 3 Aug 2010 00:48:07 +0200 Received: (qmail 47282 invoked by uid 500); 2 Aug 2010 22:47:56 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 47271 invoked by uid 99); 2 Aug 2010 22:47:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Aug 2010 22:47:56 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,SPF_PASS Received-SPF: pass (athena.apache.org: domain of markphip@gmail.com designates 209.85.212.43 as permitted sender) Received: from [209.85.212.43] (HELO mail-vw0-f43.google.com) (209.85.212.43) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Aug 2010 22:47:50 +0000 Received: by vws8 with SMTP id 8so3109733vws.16 for ; Mon, 02 Aug 2010 15:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=lhP4emKPoAV2961P+wkfqIPCZQCQl46/yCKFRht3r3c=; b=xecKsg2bpi7wXQZ/izNyxiuUoqdVJlmvsauwoDXYyPP2z25TC4CfyB/+W2cZ9E1gYH yqnRQiE9kQsW+B2NVViNWlGtkAa6SljinZ7c0EoynLph0SC8OFn10cFBuDoAU7VQmrmX 7E2GShOHHtpeJvTXU3WlOKlcsh1yPr7mwz0ro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=Z3iRPjy45wbJ6jqmF5n4T/yuZ4WUqWQ7SDRcn6UmSqiEn86IqmQZ+MWBABxoVJTHEV WWW8fv0+lcmF2+mCWt+W01qw7vuZ+Ch64XwUSJ6n/F7x6m2l9UzTS55TcYWK1oNANDg7 Z9UtzKC/NPEb2Yl+BXjVMj3P8n7mmDa7ze4tc= Received: by 10.220.60.75 with SMTP id o11mr4657126vch.131.1280789248813; Mon, 02 Aug 2010 15:47:28 -0700 (PDT) Received: from [192.168.1.211] (rrcs-24-39-68-157.nys.biz.rr.com [24.39.68.157]) by mx.google.com with ESMTPS id v9sm3288111vcy.10.2010.08.02.15.47.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 15:47:28 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A306) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-52--313168033 Message-Id: <4B538CFB-13A4-49AC-96AE-B2F2C11E7C0A@gmail.com> Cc: "users@subversion.apache.org" X-Mailer: iPhone Mail (8A306) From: Mark Phippard Subject: Re: corrupt revision, "Reading one svndiff window read beyond the end of the representation" Date: Mon, 2 Aug 2010 18:47:04 -0400 To: Justin Georgeson X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Tue, 03 Aug 2010 00:48:07 +0200 (CEST) X-Friend: Nope --Apple-Mail-52--313168033 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Have you tried fsfsverify.py? Sent from my iPhone On Aug 2, 2010, at 6:39 PM, Justin Georgeson wrote: > I have a repo with >39k revisions. Last week, r39245 was committed, a merg= e of a single file from trunk to branch. It is the HEAD revision of that fil= e on that branch. Turns out this revision is corrupt > =20 > [svnadmin@hourdcm3 ~]$ svnadmin verify -r 39245 /repos/prowess > svnadmin: Reading one svndiff window read beyond the end of the representa= tion > =20 > I've searched from r30000 to HEAD in this repo and that's the only rev tha= t fails the verify. All our backup copies have the same issue too. I'm wonde= ring what our options for recovery are. Some suggestions we have come up wit= h internally are: > =20 > 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 t= he 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, re= do 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, merg= e dumps, create new repo, redo merge > =20 > Is there something else we missed? Which of these seems like the safest/ea= siest? > =20 > This e-mail, including any attached files, may contain confidential and pr= ivileged information for the sole use of the intended recipient. Any review,= use, distribution, or disclosure by others is strictly prohibited. If you a= re not the intended recipient (or authorized to receive information for the i= ntended recipient), please contact the sender by reply e-mail and delete all= copies of this message. --Apple-Mail-52--313168033 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Have you tried fsfsverify.py?

Sent from my iPhone

On Aug 2, 2010, at 6:39 PM, Justin Georgeson <JGeorgeson@lgc.com> wrote:

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
 
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
 
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.
--Apple-Mail-52--313168033--