On Sun, Aug 30, 2009 at 7:26 PM, Akos Maroy<maroy_at_euedge.com> wrote:
> Hi,
>
> I have a corrupted subversion repository, where svnadmin verify tells me:
>
> svnadmin: Decompression of svndiff data failed
>
>
> I tried to run sfsfverify -f on the specific revision file, but to no
> avail :( it always stops at the same part, and still tells me it's broken.
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).
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.
> I have several up-to-date checked-out working copies of the repository,
> so if only I could make the repository 'stable', even if some changesets
> would be lost, I could just re-commit those changes to the repository
> itself. but I can't seem to make this corrupt revision fixed.
You could use fsfsverify to truncate the node that's corrupted,
*but*--and you really need to pay attention here--that can be really
dangerous in that *any revision* that points to that node would be
broken as well. I've seen many cases where several commits were made,
and only a single revision was actually corrupted, but the commits
that came after referred to the corrupted one and didn't have an issue
because the structures where cached in memory and didn't have to read
what was on the disk. IOW, truncating a node can reveal more issues.
Additionally, you're altering history, and that may affect you
developer's working copies as well.
> what is the recommended methodology here? delete all revisions starting
> with the corrupt one? can one 'omit' this corrupt revision somehow?
>
> any help would be appreciated..
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.
You could try dumping and loading, skipping the bad revision... but
that ends up being more problematic than helpful in most cases. :-(
-John
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2388772
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-31 09:22:57 CEST