From users-return-15833-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Tue Aug 14 22:13:56 2012 Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2381ADA66 for ; Tue, 14 Aug 2012 22:13:56 +0000 (UTC) Received: (qmail 91157 invoked by uid 500); 14 Aug 2012 22:13:55 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 91119 invoked by uid 500); 14 Aug 2012 22:13:55 -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 91112 invoked by uid 99); 14 Aug 2012 22:13:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Aug 2012 22:13:55 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [66.111.4.29] (HELO out5-smtp.messagingengine.com) (66.111.4.29) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Aug 2012 22:13:47 +0000 Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D7B162064C; Tue, 14 Aug 2012 18:13:26 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 14 Aug 2012 18:13:26 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= daniel.shahaf.name; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=mesmtp; bh= EfWRVoPU0OD0J4kQcpZgIerxwuE=; b=hHpz2I4sguAAntrsTjdeUkyybTV58Co8 /t5MyNS+iMXrgrkqLK4hvh59CFMfUDb7tKIzrDuFp1lhHb7X8HVA1ATdc01fBMcc XP/zm5gu6KRJvrVfSuHpA4TSsnMBi+VPFXlpDlkttxGpLM9bbCNPPaN3DcUA7cn8 aQ1ZCOjvmIQ= 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=EfWRVoPU0OD0J4kQcpZgIerxwuE=; b=dI9RDrzWvEqvh4rsDQbx7Plcv2Ej +dsv73WMOsi7jkur11AFfBk5327wAA+5yMlhcQ1WnKG5BSprh4si02Yr/D1+g8Dl 5izpvY4F+rtgsvaulwzPck8Xlui1DIH3SHNPGgIyxFfiCkVuVQGUDIgEIgFF9Eia az+dfnTxffogwP8= X-Sasl-enc: yX3Ggj38PnOfNo31LT6e9p8RbINsuIQKRB9zpIrAAkmQ 1344982406 Received: from tarsus.local2 (unknown [131.111.242.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 60677482597; Tue, 14 Aug 2012 18:13:26 -0400 (EDT) Date: Tue, 14 Aug 2012 23:13:25 +0100 From: Daniel Shahaf To: Trent Fisher Cc: users@subversion.apache.org Subject: Re: Repairing or removing broken revisions Message-ID: <20120814221325.GB13976@tarsus.local2> References: <5029B3B1.3090008@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5029B3B1.3090008@oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Trent Fisher wrote on Mon, Aug 13, 2012 at 22:10:57 -0400: > > > On 08/01/2012 10:49 AM, Johan Corveleyn wrote: > >On Wed, Aug 1, 2012 at 2:24 PM, Joachim Sauer wrote: > >>Hello, > >> > >>I'm currently reworking backups of multiple SVN repositories. In the > >>process I found out that one of those repositories has three broken > >>revisions. The problem is that the revision files in the revs > >>directory for those 3 revisions are of size 0 (those contain the > >>actual data of the revision, as far as I understand). This means that > >>I can't use svn dump (as it stops at that broken revision) and I can't > >>use svnsync. > >> ... > >> > >>But a broken repository is not desirable and I should attempt to fix > >>it as much as possible. Losing the information of those three > >>revisions (and a few related ones, probably) would not be a major > >>problem, but the repository as a whole should be in a consistent state > >>(to allow svnadmin dump to work, for example). > >Since you know the affected paths, I think one possible way is to do > >an svnsync, while excluding the "corrupted paths" by way of path-based > >authz (i.e. make the affected paths unreadable by the svnsync user, > >using an authz file on the source repository). After that, re-import > >the "corrupted files" from one of your working copies. > > > >I think everyone will have to re-checkout though, because you'll have > >a new repository with slightly altered history. So it wouldn't be safe > >to give this new repository the same repos-uuid, and act like it's the > >same. > > > >If you search the mailinglist archives, you might find some more posts > >about this svnsync recovery trick (excluding broken files). > > > I had a similar situation, though I only had one damaged revision. I > did a dump in three segments, up to the bad rev, the bad rev and the > remaining revs, something like this (assuming rev 44445 is the bad > one): > > svnadmin dump -r0:44444 /some/repos > p1 > svnadmin dump --incremental -r44445 /some/repos > p2 Did this actually work? If the r44445 rev file is 0 bytes long, it should fail immediately. (The same is true for the r44445 revprops file, but for a different reason.) > svnadmin dump --incremental -r44446:HEAD /some/repos > p3 > > Then I manually doctored p2 to indicate that the rev is broken (but > leave the original comment intact), then load all three into a fresh > repository (cat p1 p2 p3 | svnadmin load /some/new/repos) > > The advantage of this is that the uuid and rev numbers remain the > same, so existing workspaces will work. And this would preserve all > other history of the given file. > > I just did this on a production repository two weeks ago, and no > complaints so far. > > trent... >