Looking through scrollback, I saw the following message on #svn:
i removed __db* and log* as explained in the faq, and then the first
10 revisions (out of around 800) were extractable, but then i got a
lot of bdb errors
I was a little horrified that the user might find advice like that; as
far as I know, removing the log* files is a highly destructive
operation. I found the FAQ item:
Q. I'm getting the error "svn: bdb: call implies an access method
which is inconsistent with previous calls". How do I fix this?
Berkeley DB 4.1 has shown itself to be rather unstable - both 4.0
and 4.2 are better. This error message is a symptom of one unique
way in which 4.1 will sometimes break
The problem is that the database format field for one of the tables
that make up a Subversion BDB-type repository has become corrupted.
For unknown reasons, this is almost always the 'copies' table, which
switches from the 'btree' type to the 'recno' type. Simple recovery
procedures are outlined below - if they do not succeed, you should
contact the Subversion Users mailing list.
* Ensure that no other processes will attempt to access your
repository.
* Now, back up your repository to a tar or zip file or similar.
* Change to the db subdirectory of your repository.
* rm __db.* log.*
* db_dump -p -r copies > copies.dump
* Now edit copies.dump. In the section near the top, change
"type=recno" to "type=btree", and delete the line beginning
"re_len=".
* rm copies
* db_load copies < copies.dump
* svnadmin dump .. > ../../my-recovered.svndump
* Now create a new repository, reload the dump file just produced,
and copy across any custom hooks or configuration. Verify that
the highest revision number in the new repository is what you
think it should be.
Is it really necessary to remove the log files as well as the DB
environment in this recovery operation? And if so, can we make a note
NOT to engage in this recovery operation if you haven't seen the
specific error mentioned in the question? (Not that I expect the note
to dissuade many of the users who are likely to apply recovery
procedures for one situation to another, but we ought to try.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 21 18:33:08 2005