Re: Subversion Berkeley DB error

Listman wrote:
>
>
> 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?

My point was that even serving the repository using svn:// or http://, you can
still host the repository on an NFS volume instead of locally attached storage.
  In this case, unless you have a good NFS server, one should not use BDB and
only use FSFS.

You may want to do this if you have very reliable storage (NetApp) but have
commodity servers, so you don't care if the svn server hardware dies, just put a
new box there and have it continue to serve the repository on the NetApp.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<blair_at_orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org