Mike Dewhirst wrote:
> sorry - I reported the wrong version it is really 1.1.3-7.1 and
> further to my last email (below) I have ...
> 5. chmod -R 777 /srv/svn/repos/fbscripts
> 6. chown -R wwwrun /srv/svn/repos/fbscripts
> 7. chgrp -R www /srv/svn/repos/fbscripts
> ... and I'm still getting a commit failure through Tortoise on a Win
> XP box - like this ...
> PROPFIND request failed on '/repos/fbscripts/trunk'
> PROPFIND of '/repos/fbscripts/trunk': 500 Internal Server Error
> (http://svn.webserver ...)
> Mike Dewhirst wrote:
>> Would someone please set me right?
>> I have ...
>> 1. logged in as root
>> 2. created new directory /srv/svn/repos/fbscripts
>> 3. chmod 777 /srv/svn/repos/fbscripts
>> 4. # /usr/bin/svnadmin create /srv/svn/repos/fbscripts
>> svn: Berkeley DB error while creating environment for
>> filesystem /srv/svn/repos/fbscripts/db:
>> Invalid argument
>> svn: bdb: Berkeley DB library configured to support only
>> DB_PRIVATE environments
>> It actually created all the usual files and directories in
>> /srv/svn/repos/fbscripts but I can't import my firebird scripts.
>> The ./db directory as created is rwxr-sr-x but I don't know what that
>> Is there a limit to the number of repositories I'm allowed to have?
>> This was the seventh. The others are all working and I think I
>> followed the same procedure.
>> subversion 1.0.0-51 running on SuSE 9.1
I know -- google is my friend :)
Specify that the environment will only be accessed by a single
process (although that process may be multithreaded). This flag has two
effects on the Berkeley DB environment. First, all underlying data
structures are allocated from per-process memory instead of from shared
memory that is potentially accessible to more than a single process.
Second, mutexes are only configured to work between threads.
This flag should not be specified if more than a single process is
accessing the environment because it is likely to cause database
corruption and unpredictable behavior. For example, if both a server
application and the Berkeley DB utility db_stat are expected to access
the environment, the DB_PRIVATE flag should not be specified.
OK - so interpreting as maybe I should reboot Linux in case another
process had its finger on the ./db folder - I did - but it made no
difference. The only session alive after the reboot and logging off my
usual self was root.
Does anyone have any advice for me?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon May 2 11:40:08 2005