On Jun 16, 2009, at 07:52, Marco Eckstein wrote:
> assume the following situation:
> -Subversion server version is 1.3.x
> -FSFS backend
> -Windows XP
> -Exactly one revision is corrupted. This can be found out by using
> svnadmin verify -r 0:NumberOfCorruptedRevision and svnadmin verify -r
> NumberOfCorruptedRevision+1:HEAD, executed on a copy of the repository
> and Subversion 1.5.
> -A backup of an uncorrupted repository including revision
> NumberOfCorruptedRevision exists.
> Consider the following attempt to repair the repository:
> -Temporarily disable all Subversion client access to the repository
> -Overwrite the file myRepository\db\revs\NumberOfCorruptedRevision
> Is this the correct way to restore a corrupted revision?
If it is the contents of the revision that was corrupted, then yes,
that should be it. If it was the properties of the revision that were
corrupted, then you would deal with the file in db\revprops instead
> Unfortunately, I found no definite answer to that question, just a
> statement in the book "Version Control with Subversion" (for
> 1.5) on page 314 about svnadmin verify which states: "If this command
> fails (...) that means your repository has at least one corrupted
> revision, and you should restore the corrupted revision from a
> backup (...)"
> The approach definitely SEEMS to work, which can be seen when
> testing it
> and running a successful svnadmin verify. However, I want to be sure
> that there are no ill effects. After all I do not know how svnadmin
> verify works in detail and how much it can be trusted.
If it's working now, then I'd agree you've fixed the problem.
As far as I know, for FSFS repositories, svnadmin verify verifies
that the files in db\revs look reasonable. One of them didn't before,
and now that you've replaced it with its backup, it's fine.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-17 02:34:01 CEST