Branko Čibej wrote:
> Philip Martin wrote:
>
>> The upgrade procedure that seems to work on my test repository is:
>>
>> - run 'svnadmin recover' using BDB 4.2
>> - remove db/_db.00?
>>
>>
> Well, there's a bug right there in "svnadmin recover", then. It should
> remove the environment files itself.
And I've found that bug. We were passing both "DB_INIT_LOCK" and
"DB_PRIVATE" when opening the environment for recovery. db_recover does
one _or_ the other, but never both. It uses DB_PRIVATE when it doesn't
want to retain the environment files (and we never want to do that).
>
>> - remove or archive db/log.*
>>
>>
> Ouch! This is *not* good.
The BDB docs say this:
If the application has a Berkeley DB transactional environment, and the
log files need upgrading but the databases do not, the application may
be installed in the field using the following steps:
1. Shut down the old version of the application.
2. Run recovery on the database environment using the DB_ENV->open
<cid:part1.02080604.04080005@xbc.nu> method or the db_recover
<cid:part2.07000705.01010802@xbc.nu> utility.
3. Remove any Berkeley DB environment using the DB_ENV->remove
<cid:part3.09000105.03090800@xbc.nu> method or an appropriate
system utility.
4. Archive the database environment for catastrophic recovery. See
Archival procedures <cid:part4.04090706.07010703@xbc.nu> for more
information.
5. Recompile and install the new version of the application.
6. Restart the application.
Step 3. should be happening automatically, but this says nothing about
removing log files that are in use. So I guess doing "svnadmin recover"
and removing the environment files should be enough.
I'll fix svnadmin recover, of couse, and propose the change for backport
to 1.1.x.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 5 23:51:24 2005