Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of jcorvel@gmail.com designates
 209.85.212.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAANA7ifMXd2Q4_vLGNxdzpXvjZrSuD0mOMUMdFNsJFrQeQ8TCg@mail.gmail.com>
References: 
 <CAANA7ifMXd2Q4_vLGNxdzpXvjZrSuD0mOMUMdFNsJFrQeQ8TCg@mail.gmail.com>
From: Johan Corveleyn <jcorvel@gmail.com>
Date: Wed, 1 Aug 2012 16:49:31 +0200
Message-ID: 
 <CAB84uBUnwawWr5ObF64O1BgATWeOJ4T+oRQn_+AS=e_zCrDg0A@mail.gmail.com>
Subject: Re: Repairing or removing broken revisions
To: Joachim Sauer <saua@gmx.net>
Cc: users@subversion.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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).

-- 
Johan