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

Re: Potentially destructive FAQ answer (attn maxb)

From: Max Bowsher <maxb_at_ukf.net>
Date: 2005-01-21 22:45:12 CET

Greg Hudson wrote:
> 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.)

I can't imagine that I would have added it unless the initial attempt
without it failed, in the case which actually drove me to write that FAQ.
That said, I do feel a bit uneasy about having potentially dangerous advice
so exposed. At very least, "back up your repository" should become "BACK UP
YOUR REPOSITORY".

Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 21 22:48:07 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.