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

Re: recovering a repository

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-09-05 00:46:00 CEST

On Sep 4, 2007, at 16:07, Kamaraju S Kusumanchi wrote:

> Ryan Schmidt wrote:
>
>>>>> I do not know for sure what it should contain, but something
>>>>> around
>>>>
>>>> 132 d 1
>>>>
>>>> would be a good content perhaps. If it does not contain this
>>>> contents,
>>>> perhaps try to modify it and retry svnadmin verify ...
>>>
>>> Now when I changed it to
>>>
>>> $svnadmin verify /home/rajulocal/src/repos/
>>> * Verified revision 0.
>>> * Verified revision 1.
>>> * Verified revision 2.
>>> * Verified revision 3.
>>> * Verified revision 4.
>>> * Verified revision 5.
>>> * Verified revision 6.
>>> * Verified revision 7.
>>> .....
>>> * Verified revision 119.
>>> * Verified revision 120.
>>> * Verified revision 121.
>>> * Verified revision 122.
>>> * Verified revision 123.
>>> * Verified revision 124.
>>> svnadmin: Revision file lacks trailing newline
>>>
>>> So it seems now it is working upto revision 124. Any idea how to get
>>> further?
>>
>> Do you have a backup of the 124 file you could restore? If not, what
>> is the contents of the 124 file now? Does it look reasonable (that
>> is, does it look similar in shape to the content of the previous
>> revision files that verified correctly)?
>>
>
> The contents of db/revs/124 look reasonable. However the contents of
> db/revs/125 is not good. It is basically a bunch of ^@. When I
> tried to cat
> it, nothing is printed on the command line. However the contents of
> db/revs/125, db/revs/126 etc., all look reasonable upto revision 132.

Oh, yes, sorry, of course, it said it verified revision 124, and then
it threw an error, so yes, revision 125 is the one it's complaining
about. And you've discovered it's corrupted and you have no backup.
So now you have a problem.

Subversion stores revisions as deltas against previous revisions.
Hopefully, none of your revisions 126 thru 132 depend on revision
125. (The skip-deltas algorithm determines which previous revision is
used for the delta.) And hopefully the information you committed in
revision 125 wasn't important, because it's gone now.

The only "solution" I can think of is to "svnadmin dump" revisions 0
thru 124, and 126 thru 132, "svnadmin create" new repository,
"svnadmin load" the first dumpfile and then the second dumpfile into
the new repository. Then check out new working copies from the new
repository. You should now have a repository which is not corrupted,
but it won't contain anything from revision 125.

If you still have old working copies from the old repository, you
could compare them (using external diff utilities) to the contents of
a fresh checkout from the new repository. If there are any
differences, perhaps those are the differences that were lost in
r125, and you could re-do those changes in the new working copy and
commit them as a new revision, thus saving what was in r125.

In the future, make sure you back up your repository religiously.
Creating a backup in the post-commit hook is the best idea, so that
the backup gets created the instant the original gets created, so
there's no chance for any data loss.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 5 00:44:29 2007

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.