You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2005/01/21 17:25:11 UTC
Potentially destructive FAQ answer (attn maxb)
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
Re: Potentially destructive FAQ answer (attn maxb)
Posted by Joseph Galbraith <ga...@vandyke.com>.
Brian W. Fitzpatrick wrote:
>
> On Jan 21, 2005, at 6:27 PM, Justin Erenkrantz wrote:
>
>> --On Friday, January 21, 2005 9:45 PM +0000 Max Bowsher <ma...@ukf.net>
>> wrote:
>>
>>> 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".
>>
>>
>> How about placing the answer to this question on a separate page?
>
>
> I like this idea. The link text can be
>
> "YES, I HAVE BACKED UP MY REPOSITORY, let me see the instructions"
>
> :)
Maybe there should also be a link to instructions in the
book or a faq "How do a backup my repository" or even
just a note: "A straight file copy will backup your
repository in case the following (dangerous) procedure does
not work."
Thanks,
Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Potentially destructive FAQ answer (attn maxb)
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Jan 21, 2005, at 6:27 PM, Justin Erenkrantz wrote:
> --On Friday, January 21, 2005 9:45 PM +0000 Max Bowsher <ma...@ukf.net>
> wrote:
>
>> 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".
>
> How about placing the answer to this question on a separate page?
I like this idea. The link text can be
"YES, I HAVE BACKED UP MY REPOSITORY, let me see the instructions"
:)
> And, perhaps add in "(THIS MEANS YOU!)" to that step on backups. This
> way casual browsers won't see it unless they click on it. But,
> deleting the log* files is a very, very dangerous thing to do. The
> __db* files are *usually* not as relevant and are recreated with
> db_recover. -- justin
*nod*
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Potentially destructive FAQ answer (attn maxb)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, January 21, 2005 9:45 PM +0000 Max Bowsher <ma...@ukf.net>
wrote:
> 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".
How about placing the answer to this question on a separate page? And,
perhaps add in "(THIS MEANS YOU!)" to that step on backups. This way
casual browsers won't see it unless they click on it. But, deleting the
log* files is a very, very dangerous thing to do. The __db* files are
*usually* not as relevant and are recreated with db_recover. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Potentially destructive FAQ answer (attn maxb)
Posted by Travis P <sv...@castle.fastmail.fm>.
On Jan 21, 2005, at 3:45 PM, Max Bowsher wrote:
> Greg Hudson wrote:
>> * Change to the db subdirectory of your repository.
>> * rm __db.* log.*
>> ....
>> Is it really necessary to remove the log files as well as the DB
>> environment in this recovery operation
> 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".
You could remain on the extra-safe side and beside capitalizing "BACK
UP..." also recommend that rather than removing the logs that they mv
them into an new "oldlogs" subdirectory until they are sure this
recovery operation worked. Once they are confident they've got their
repos back, they can then delete them.
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Potentially destructive FAQ answer (attn maxb)
Posted by Max Bowsher <ma...@ukf.net>.
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