Re: Dealing with Subversion (Berkeley DB) Recovery {IUse DarwinPorts!}
Re: Dealing with Subversion (Berkeley DB) Recovery {IUse DarwinPorts!}
- Subject: Re: Dealing with Subversion (Berkeley DB) Recovery {IUse DarwinPorts!}
- From: "Frederick C. Lee" <email@hidden>
- Date: Sat, 21 Aug 2004 11:53:10 -0700
I've been using DarwinPorts to do all the dirty work.
It would be nice to determine which DB file contains the version
number; or better yet, some sort of interactive routine like:
$> db --version
to display the version number.
Wait...
I just remember that I can do the following using DarwinPorts:
[/usr/local] port installed
The following ports are currently installed:
apr 0.9.5_2 (active)
apr-util 0.9.5_1 (active)
db4 4.2.52_0+darwin_7 (active) <--- Current version of
Berkeley DB installed.
expat 1.95.7_0 (active)
libiconv 1.9.2_0 (active)
neon 0.24.7_0 (active)
sqlite 2.8.13_0 (active)
subversion 1.0.6_0 (active)
vile 9.4_0 (active)
[/usr/local]
I strongly recommend installing DarwinPorts!
Ric.
On Aug 20, 2004, at 8:23 PM, Dennis C. De Mars wrote:
> I went through this shortly after trying to use Subversion. After just
> a few revisions I got a DB error and neither svnadmin recover or
> running the Berkeley DB db_recover tool fixed things.
>
> I did find that running svnadmin dump worked without error and then
> doing an svnadmin load on the resulting file recovered the original
> repository with all of the revisions. I was disillusioned at first
> since the Subversion docs made it sound as if the whole Subversion
> system was pretty secure, but I was somewhat mollified when the
> dump/load sequence restored everything (demonstrating that all of the
> data really had been preserved).
>
> I attribute pretty much 100% of my problems with Subversion to
> Berkeley DB, so when they came out with the alternate back end (FSFS)
> i switched to that immediately, and haven't had any problems so far.
> It isn't in final release yet, but 1.1rc2 (release candidate 2) is
> available.
>
> To answer your questions, if you are using a fairly up-to-date version
> of Subversion, it is using Berkeley DB 4.2 but you probably don't have
> the whole 4.2 distribution. So you can download the latest revision of
> 4.2 and try that. You need to download the latest distribution from
> sleepycat and build & install it.
>
> But based on my experience, I wouldn't bother. I'd try using dump/load
> to recover, and if that doesn't work, then try the complete Berkeley
> DB 4.2 installation. Once you recover, consider moving to Subversion
> 1.1rc2 and fsfs (you can dump from your bdb repository and load into
> an fsfs repository).
>
> - Dennis D.
>
> On Aug 20, 2004, at 10:53 AM, Frederick C. Lee wrote:
>
>> Greetings:
>>
>> I'm (Neophyte) trying to use Subversion v1.0.6 and am encountering
>> DB problems with Berkeley DB. I've read through the Subversion PDF
>> and it mentioned a version of Berkeley DB to be used. The PDF
>> essentially says to keep my hands off of Berkeley
>> (/usr/local/svn_repository/db) and to run the svnadmin recover
>> command. That failed as shown below.
>>
>> -------------
>> [/Users/Ric]svnadmin recover /usr/local/svn_repository
>> Please wait; recovering the repository may take some time...
>> svn: DB_RUNRECOVERY: Fatal error, run database recovery
>> [/Users/Ric]
>>
>>
>> ...a possible clue to the problem:
>> 1)
>> [/Users/Ric]svnlook info /usr/local/svn_repository
>> root
>> 2004-08-19 17:26:25 -0700 (Thu, 19 Aug 2004)
>> 50
>> Enhanced data path check and cityController window
>> svn: Berkeley DB error while closing 'nodes' database for filesystem
>> /usr/local/svn_repository/db:
>> DB_RUNRECOVERY: Fatal error, run database recovery
>> [/Users/Ric]
>>
>>
>> 2)
>> [/Users/Ric]svnadmin list-unused-dblogs /usr/local/svn_repository
>> Segmentation fault
>> [/Users/Ric]
>>
>> ---------------
>>
>>
>> 1) How do I determine the version number of Berkeley DB installed on
>> my system?
>> 2) How do I do command-line DB_RUNRECOVERY of Berkeley DB?
>>
>> Fortunately I don't have a lot of files in DB at present. I'm
>> thinking of running the svnadmin dump & load to flush the problem
>> away; if this does work. But I would like to know how to handle
>> such recovery hassles as they're probably occur over & over in the
>> future.
>>
>> Regards,
>>
>> Ric.
>> _______________________________________________
>> xcode-users mailing list | email@hidden
>> Help/Unsubscribe/Archives:
>> http://www.lists.apple.com/mailman/listinfo/xcode-users
>> Do not post admin requests to the list. They will be ignored.
> _______________________________________________
> xcode-users mailing list | email@hidden
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/xcode-users
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.