On 08/01/2012 10:49 AM, Johan Corveleyn wrote:
On Wed, Aug 1, 2012 at 2:24 PM, Joachim Sauer <s...@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...
