Philip Martin wrote:
>Branko ÄŒibej <brane@xbc.nu> writes:
>
>
>
>>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.
>>
>>
>
>svn_repos_recover2() does remove the environment, however
>'svnadmin recover' open the recovered repository to read the
>youngest revision and so the environment is recreated.
>
>
Ah. You're right, I missed that part. So /that/ is the bug in "svnadmin
recover". It's sheer nonsense keep the old-format environment files
around when you recover the database, becasue that will always make the
newer version of BDB choke. In other words, "svnadmin recover" as it
stands now is useless for upgrading BDB repositories.
>>>- remove or archive db/log.*
>>>
>>>
>>>
>>>
>>Ouch! This is *not* good.
>>
>>
>>
>>>Then just start using BDB 4.3, there is no need to run a 4.3 recover
>>>although it doesn't do any harm. Note that I have to remove all the
>>>log files, even those not designated "unused", I don't know under
>>>what circumstances this is safe.
>>>
>>>
>>>
>>Never, according to the BDB docs.
>>
>>
>
>4.3 recovery doesn't work with 4.2 log files, even using native BDB
>tools.
>
Yes. But read my other post: The DB docs say to recover with the old
version, but _not_ with the new version, and to leave the logs alone.
Just remove the unused logs, and start using the database. I suppose
that's why doing "svnlook youngest" before using the new svnadmin
recover usually works.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 6 00:16:42 2005