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

Potentially destructive FAQ answer (attn maxb)

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-01-21 18:25:11 CET

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
    * 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
    * 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.