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