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 <saua_at_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.
> >>
...
> >>
> >>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...
>
Received on 2012-08-15 00:14:01 CEST