John,
> 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,
how?
> 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..
Akos
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2388847
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-31 13:16:32 CEST