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

Re: Moving to FSFS - svn dump throws Unknown FS type 'bdb'

From: Ben Jackson <ben_at_incomumdesign.com>
Date: 2005-04-30 23:48:03 CEST

More news on this issue:

I tried to create a new database from scratch with the following command:

svnadmin create ./svn --fs-type=fsfs

This went fine. However, when I try to access this fresh repository I get:

<D:error>
<C:error/>
<m:human-readable errcode="160029">
Could not open the requested SVN filesystem
</m:human-readable>
</D:error>

Ben Jackson wrote:

>> Ben Jackson wrote:
>>
>>> The server itself is running ok doing checkouts, updates and commits...
>>> however it's flaky and sometimes needs some time to chill out before it
>>> lets us connect again. I assume this is due to BDB's inherent
>>> instability with multiple users.
>>
>>
>>
>> Umm, wow. I do not think BDB has any "inherent instability with
>> multiple users".
>>
>
> From http://svnbook.red-bean.com/en/1.1/ch05.html#svn-ch-5-sect-1.3:
>
>> Finally, because Berkeley DB is a library linked directly into
>> Subversion, it's more sensitive to interruptions than a typical
>> relational database system. Most SQL systems, for example, have a
>> dedicated server process that mediates all access to tables. If a
>> program accessing the database crashes for some reason, the database
>> daemon notices the lost connection and clean up any mess left behind.
>> And because the database daemon is the only process accessing the
>> tables, applications don't need to worry about permission conflicts.
>> These things are not the case with Berkeley DB, however. Subversion
>> (and programs using Subversion libraries) access the database tables
>> directly, which means that a program crash can leave the database in
>> a temporarily inconsistent, inaccessible state. When this happens, an
>> administrator needs to ask Berkeley DB to restore to a checkpoint,
>> which is a bit of an annoyance. Other things can cause a repository
>> to “wedge” besides crashed processes, such as programs conflicting
>> over ownership and permissions on the database files. So while a
>> BerkeleyDB repository is quite fast and scalable, it's best used by a
>> single server process running as one user—such as Apache's *httpd* or
>> *svnserve* (see Chapter 6, /Server Configuration/
>> <http://svnbook.red-bean.com/en/1.1/ch06.html>)—rather than accessing
>> it as many different users via file:/// or svn+ssh:// URLs. If using
>> a Berkeley DB repository directly as multiple users, be sure to read
>> the section called “Supporting Multiple Repository Access Methods”
>> <http://svnbook.red-bean.com/en/1.1/ch06s05.html>.
>
>
>
> So do I update BDB, update SVN, or both? I'm running BDB 4 (I think,
> how do I confirm this?) and SVN 1.13.
>
>>> Do you still think it's an incompatibility?
>>
>>
>>
>> I never thought it was an incompatibility in the first place.
>>
>>
>>> Max Bowsher wrote:
>>>
>>>> Ben Jackson wrote:
>>>>
>>>>> Trying to do an svnadmin dump and get the "Unknown FS type 'bdb'"
>>>>> error.
>>>>> Maybe this is the problem?
>>>>>
>>>>> http://svn.haxx.se/users/archive-2005-04/0499.shtml
>>>>>
>>>>> In which case maybe the db is incompatible with the recent SVN 1.1
>>>>> upgrade... I installed the binary and prayed (I know, I'm naive). Any
>>>>> ideas? I want to transition to FSFS, and this is the only way that I
>>>>> know how.
>>>>
>>>>
>>>>
>>>>
>>>> It seems this binary you have installed does not support bdb.
>>>> You need to find or compile one which does.
>>>>
>>>>
>>>> Max.
>>>
>>>
>>
>

-- 
Ben Jackson
Diretor de Desenvolvimento
INCOMUM Design & Conceito
+55 (21) 9997-0593
ben@incomumdesign.com
http://www.incomumdesign.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Apr 30 23:52:07 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.