On 08/14/2012 06:13 PM, Daniel Shahaf wrote:
> 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.)
>
Yes, it did. I guess it depends on the sort of corruption there is. In
my case, the dump generated a truncated, invalid dump file: It cut off
right before the contents of a file. So I removed that last header and
modified the log entry.
But, you're right, the original poster said his files were zero length.
In that case you'd have to cobble together a fake dump file for that
broken revision.
The rest of the process would stand, however.
trent...
Received on 2012-08-17 21:09:12 CEST