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