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

Re: Subversion Berkeley DB error

From: Listman <listman_at_burble.net>
Date: Sat, 15 Mar 2008 20:44:43 -0700

On Mar 14, 2008, at 5:22 PM- Mar 14, 2008, Blair Zajac wrote:

> Troy Curtis Jr wrote:
>> On Fri, Mar 14, 2008 at 2:42 PM, Ryan Schmidt
>> <subversion-2008a_at_ryandesign.com> wrote:
>>> On Mar 14, 2008, at 00:38, <geetha.kirubakaran_at_wipro.com>
>>>
>>> <geetha.kirubakaran_at_wipro.com> wrote:
>>>
>>> > I (Admin) created the repository and i did a checkout of the
>>> > repository. The repository has directories created for each member
>>> > in the project.
>>> >
>>> > Initially, the admin as well as the users were able to do a
>>> > checkout in their working directory/logn\in.
>>> >
>>> > But later, when i(as admin) did a checkout of the repository, it
>>> > gave some message saying "needing recovery". So i did svnadmin
>>> > recover repos path. Once done I(admin) is able to do checkout and
>>> > checkin.
>>> >
>>> > But users are not able to do checkout even after this.
>>> >
>>> > Everybody(Users) when they use svn commands or when they do a
>>> > checkout they get error message as follows:
>>> >
>>> > svn: Unable to open an ra_local session to URL
>>> > svn: Unable to open repository 'file:///home/ams_admin/
>>> > TRAINING_BATCH_07/repository/.svn_repository/trunk'
>>> > svn: Berkeley DB error while opening environment for filesystem /
>>> > home/ams_admin/TRAINING_BATCH_07/repository/.svn_repository/db:
>>> > I feel this is something related to the dB config file in dB
>>> > directory. Could you please tell me how should i proceed.
>>> >
>>> > Could you please help me out in this?
>>>
>>> Several users accessing a repository via the file:///-protocol is a
>>> recipe for disaster. Please switch to using svnserve or apache to
>>> serve your repository, and put the repository itself in a location
>>> where only the user under which these services are running can read
>>> from and write to the repository.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
>>> For additional commands, e-mail: users-help_at_subversion.tigris.org
>>>
>>>
>> Right, and the REASON for this is permissions. There are a lot of
>> files that get opened, read, and written to. To do it right you have
>> to be very careful that all the users have the same primary group and
>> that the appropriate umask is set up so that all the files the users
>> create/modify have group write permissions and are owned by the right
>> group. And all this assumes that you are running a *nix variant.
>> I'm
>> not sure what you have to do on Windows.
>> In other words it is a LOT easier to have just one user accessing the
>> repository files directly, and that is whatever user is running the
>> svnserve or apache process. Apache can be a little tricky to get
>> working just right (not TOO bad for a simple setup), but svnserve is
>> very easy.
>> Personally I always like to know WHY I shouldn't do something.
>
> If the repository is on NFS, then you need a good NFS server that
> supports locks to ensure that a BDB repository works. Using a
> NetApp NFS server is safe, as CollabNet does that, but I'm not aware
> of using any other NFS servers.
>

using file:// requires NFS in this case since the data isn't local
(its on the netapp). svnserve uses a TCP/IP socket and negates any NFS
slowness. doesn't it make sense to *always* use svnserve when the data
isn't on a local disk? by removing NFS it should be faster then
file:// over the network, no?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-16 04:45:28 CET

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.