[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: recovering svn repository?

From: Akos Maroy <maroy_at_euedge.com>
Date: Mon, 31 Aug 2009 13:15:33 +0200


> Perhaps I should make fsfsverify loop internally. I originally wrote
> this tool to help examine a broken revision, without seeing the actual
> data involved, since some folks were unwilling to let me see the
> actual revision. It was never really targeted to fix broken repos
> (hence the name).

I understand. but as it was stopping at the same location again and
again, my presumption is that the problem cannot be fixed by fsfsverify.

> However, it has done so to great success, but one issue folks run into
> often is that the they think it'll fix everything the first time
> through... and may not. I've needed to run it upwards of a dozen
> times on some revs. However, that also depends on what the actual
> issue is. Sometimes, the fix that fsfsverify employs isn't enough,
> because you have actual data loss in there.

most probably there is..

> You could use fsfsverify to truncate the node that's corrupted,


> I generally advise folks to fix the broken revision, depending on when
> it occurred, and because of the fallout that can occur (tags, history,
> and devs can all be affected). My schedule has been pretty chaotic,
> but if you can let me see the broken revision, I've been very
> successful at recovering them. If you do have some data loss, but
> still have access to the corrupted files in their original form
> (because they were deployed, or because you have diffs in an archive,
> etc), I've also been able to recover revisions with data loss as well.
> It just depends.

I'm not actually concerned about data loss, as I have the data around to
replace it with. the problem was that the repository itself got into an
inconsistent, un-usable state.

> You could try dumping and loading, skipping the bad revision... but
> that ends up being more problematic than helpful in most cases. :-(


I ended up creating a new repository.

but it seems that subversion is quite ill-equiped to deal with large
collections of large files..



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-31 13:16:32 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.