Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of trent.fisher@oracle.com
 designates 148.87.113.117 as permitted sender)
Message-ID: <5029B3B1.3090008@oracle.com>
Date: Mon, 13 Aug 2012 22:10:57 -0400
From: Trent Fisher <trent.fisher@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: users@subversion.apache.org
Subject: Re: Repairing or removing broken revisions
References: 
 <CAANA7ifMXd2Q4_vLGNxdzpXvjZrSuD0mOMUMdFNsJFrQeQ8TCg@mail.gmail.com>
 <CAB84uBUnwawWr5ObF64O1BgATWeOJ4T+oRQn_+AS=e_zCrDg0A@mail.gmail.com>
In-Reply-To: 
 <CAB84uBUnwawWr5ObF64O1BgATWeOJ4T+oRQn_+AS=e_zCrDg0A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 08/01/2012 10:49 AM, Johan Corveleyn wrote:
> On Wed, Aug 1, 2012 at 2:24 PM, Joachim Sauer <saua@gmx.net> 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.
>>
>> For the backup itself I can still use svn hotcopy (the previous way of
>> doing a backup), so this will be my workaround.
>>
>> I was able to find out the affected paths in the repository and
>> luckily the latest revision of those paths can be checked out without
>> a problem (so we "only" lost history, not current data).
>>
>> 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).
>>
>> Is there a way to remove the broken revisions and still keep the rest
>> of the repository intact? Ideally without requiring everyone to make
>> new clean checkouts because the repository became incompatible.
>>
>> regards
>> Joachim Sauer
>>
>> P.S.: unfortunately there are no working backups of the broken
>> revisions, as the corruption seems to be pretty old (older than our
>> last full backup).
> 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
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...