subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Corveleyn <>
Subject Re: Repairing or removing broken revisions
Date Wed, 01 Aug 2012 14:49:31 GMT
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.
> 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

If you search the mailinglist archives, you might find some more posts
about this svnsync recovery trick (excluding broken files).


View raw message