From users-return-4087-daniel=haxx.se@subversion.apache.org Tue Aug 3 16:31:50 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=-4.5 required=3.0 tests=BAYES_00,DS_FRIEND, T_DKIM_INVALID,T_RP_MATCHES_RCVD autolearn=ham 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 o73EVnZc011881 for ; Tue, 3 Aug 2010 16:31:50 +0200 Received: (qmail 78622 invoked by uid 500); 3 Aug 2010 14:31:40 -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 78614 invoked by uid 99); 3 Aug 2010 14:31:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Aug 2010 14:31:39 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS Received-SPF: pass (nike.apache.org: local policy) Received: from [66.111.4.25] (HELO out1.smtp.messagingengine.com) (66.111.4.25) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Aug 2010 14:31:31 +0000 Received: from compute2.internal (compute2.internal [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 4CF2C18BB4E; Tue, 3 Aug 2010 10:31:10 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 03 Aug 2010 10:31:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=smtpout; bh=+EdJTzpjP6ji1hPVTFizWSLU2ns=; b=rb+zf+rbnRzlgNaGnQpRMaD4oXk2rERowuTpRMgwz7sN5IZ1ySulbXulxqVrH79CcrHlaom6KRzTeInsvXqu/rN5mz+i6wwVSRZQuRQ4RnTdLKO6bKlr6W2B7Oo0voo9DVcXWiShoveXVLzhiOrtvx43LqPt/S8Zg6mquEO0u+w= X-Sasl-enc: F/8qJBe5C5BBydrxUXT8QnvLICSwPTlNmbhQMaqPpDs7KxkquyDHVg+xpNYQjg 1280845869 Received: from daniel3.local (bzq-79-183-4-135.red.bezeqint.net [79.183.4.135]) by mail.messagingengine.com (Postfix) with ESMTPSA id 486F34D736; Tue, 3 Aug 2010 10:31:07 -0400 (EDT) Date: Tue, 3 Aug 2010 17:29:36 +0300 From: Daniel Shahaf To: Justin Georgeson Cc: "users@subversion.apache.org" Subject: Re: corrupt revision, "Reading one svndiff window read beyond the end of the representation" Message-ID: <20100803142936.GC17130@daniel3.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Checked: Checked by ClamAV on apache.org 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 16:31:50 +0200 (CEST) X-Friend: Friend 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.