You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Martin MAURER <ma...@email.de> on 2004/10/20 06:18:26 UTC
subversion 1.1.0 checkin crashes - repo needs recovery
Please CC in replies - not subscribed to this list.
Hi all,
I have been using svn for quite some time now, it usually works very
nicely for me. thanks for this powerful tool.
I am using version 1.1.0 with a bdb backend.
access method file://
Recently when i tried to check in some changes i got a crash.
backtrace follows:
#0 0x402c5781 in kill () from /lib/libc.so.6
#1 0x40247e5e in pthread_kill () from /lib/libpthread.so.0
#2 0x40248339 in raise () from /lib/libpthread.so.0
#3 0x402c6be1 in abort () from /lib/libc.so.6
#4 0x4009bb72 in begin_trail (trail_p=0xbffff7a4, fs=0x817f0d8,
use_txn=1,
pool=0x8061f38) at subversion/libsvn_fs_base/trail.c:111
#5 0x4009bd57 in do_retry (fs=0x817f0d8,
txn_body=0x4009b950 <txn_body_abort_txn>, baton=0x818c290,
use_txn=1,
pool=0x8061f38, txn_body_fn_name=0x400a5b2d "unknown",
filename=0x400a5b2c "", line=0) at
subversion/libsvn_fs_base/trail.c:229
#6 0x4009be5a in svn_fs_base__retry_txn (fs=0x817f0d8,
txn_body=0x4009b950 <txn_body_abort_txn>, baton=0x818c290,
pool=0x8061f38)
at subversion/libsvn_fs_base/trail.c:291
#7 0x4009b9f8 in svn_fs_base__abort_txn (txn=0x818c290, pool=0x8061f38)
at subversion/libsvn_fs_base/revs-txns.c:917
#8 0x40073509 in svn_fs_abort_txn (txn=0x818c290, pool=0x8061f38)
at subversion/libsvn_fs/fs-loader.c:416
#9 0x4006175c in abort_edit (edit_baton=0x817be60, pool=0x8061f38)
at subversion/libsvn_repos/commit.c:599
#10 0x4001d108 in svn_client_commit (commit_info=0xbffff9b4,
targets=0x8062e20, nonrecursive=0, ctx=0x80625b8, pool=0x8061f38)
at subversion/libsvn_client/commit.c:1431
#11 0x0804c0c8 in svn_cl__commit (os=0x8061f70, baton=0xbffffa28,
---Type <return> to continue, or q <return> to quit---
pool=0x8061f38) at subversion/clients/cmdline/commit-cmd.c:94
#12 0x0804eecd in main (argc=4, argv=0xbffffca4)
at subversion/clients/cmdline/main.c:1332
anyways i think the main problem is located at the server, as retrying
shows that the repo is corrupt:
svn: Commit failed (details follow):
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///svn/SVN_DATABASES'
svn: Berkeley DB error while opening environment for
filesystem /svn/SVN_DATABASES/db:
DB_RUNRECOVERY: Fatal error, run database recovery
svn: bdb: PANIC: fatal region error detected; run recovery
svnadmin recover works, but checking in again fails again.
i used this repository, checkout and subversion version for a few days
now, and up to now everything worked flawlessly. (actually this checkin
was done by a script - so it is still done by the same user, the same
way)
unfortunately the data is company data, so i cant make it available.
what should i try next ? any way to check if the server works - and get
a coredump out of it (if it crashes)
greetings
--
Martin MAURER <ma...@email.de>
Re: subversion 1.1.0 checkin crashes - repo needs recovery
Posted by Martin MAURER <ma...@email.de>.
On Wed, 2004-10-20 at 19:26 +0100, Philip Martin wrote:
> Martin MAURER <ma...@email.de> writes:
>
> > #0 0x402c5781 in kill () from /lib/libc.so.6
> > #1 0x40247e5e in pthread_kill () from /lib/libpthread.so.0
> > #2 0x40248339 in raise () from /lib/libpthread.so.0
> > #3 0x402c6be1 in abort () from /lib/libc.so.6
> > #4 0x4009bb72 in begin_trail (trail_p=0xbffff7a4, fs=0x817f0d8,
> > use_txn=1,
> > pool=0x8061f38) at subversion/libsvn_fs_base/trail.c:111
> > #5 0x4009bd57 in do_retry (fs=0x817f0d8,
> > txn_body=0x4009b950 <txn_body_abort_txn>, baton=0x818c290,
> > use_txn=1,
> > pool=0x8061f38, txn_body_fn_name=0x400a5b2d "unknown",
> > filename=0x400a5b2c "", line=0) at
> > subversion/libsvn_fs_base/trail.c:229
> > #6 0x4009be5a in svn_fs_base__retry_txn (fs=0x817f0d8,
> > txn_body=0x4009b950 <txn_body_abort_txn>, baton=0x818c290,
> > pool=0x8061f38)
> > at subversion/libsvn_fs_base/trail.c:291
> > #7 0x4009b9f8 in svn_fs_base__abort_txn (txn=0x818c290, pool=0x8061f38)
> > at subversion/libsvn_fs_base/revs-txns.c:917
> > #8 0x40073509 in svn_fs_abort_txn (txn=0x818c290, pool=0x8061f38)
> > at subversion/libsvn_fs/fs-loader.c:416
> > #9 0x4006175c in abort_edit (edit_baton=0x817be60, pool=0x8061f38)
> > at subversion/libsvn_repos/commit.c:599
>
> It looks like the commit failed before the crash, and the client then
> crashed while aborting the commit.
>
> > #10 0x4001d108 in svn_client_commit (commit_info=0xbffff9b4,
> > targets=0x8062e20, nonrecursive=0, ctx=0x80625b8, pool=0x8061f38)
> > at subversion/libsvn_client/commit.c:1431
> > #11 0x0804c0c8 in svn_cl__commit (os=0x8061f70, baton=0xbffffa28,
> > ---Type <return> to continue, or q <return> to quit---
> > pool=0x8061f38) at subversion/clients/cmdline/commit-cmd.c:94
> > #12 0x0804eecd in main (argc=4, argv=0xbffffca4)
> > at subversion/clients/cmdline/main.c:1332
>
> > svnadmin recover works, but checking in again fails again.
>
> With the same gdb stack?
yes the stack trace stays the same when i repeat this.
(i didnt activate coredumping [via ulimit] when this happened the first
time. but since then - this stack trace)
>
> > unfortunately the data is company data, so i cant make it available.
> >
> > what should i try next ? any way to check if the server works - and get
> > a coredump out of it (if it crashes)
>
> There is no server, it's the client itself you need to debug. If you
> can't do that then you need to provide enough information to allow
> someone else to reproduce the problem.
i dont know enough about subversion to debug it at the moment (and i got
limited time). I know some c/c++, so i can do minor changes if needed.
If you need further information, please tell me which. would an strace
help ?
greetings
--
Martin MAURER <ma...@email.de>
Re: subversion 1.1.0 checkin crashes - repo needs recovery
Posted by Philip Martin <ph...@codematters.co.uk>.
Martin MAURER <ma...@email.de> writes:
> #0 0x402c5781 in kill () from /lib/libc.so.6
> #1 0x40247e5e in pthread_kill () from /lib/libpthread.so.0
> #2 0x40248339 in raise () from /lib/libpthread.so.0
> #3 0x402c6be1 in abort () from /lib/libc.so.6
> #4 0x4009bb72 in begin_trail (trail_p=0xbffff7a4, fs=0x817f0d8,
> use_txn=1,
> pool=0x8061f38) at subversion/libsvn_fs_base/trail.c:111
> #5 0x4009bd57 in do_retry (fs=0x817f0d8,
> txn_body=0x4009b950 <txn_body_abort_txn>, baton=0x818c290,
> use_txn=1,
> pool=0x8061f38, txn_body_fn_name=0x400a5b2d "unknown",
> filename=0x400a5b2c "", line=0) at
> subversion/libsvn_fs_base/trail.c:229
> #6 0x4009be5a in svn_fs_base__retry_txn (fs=0x817f0d8,
> txn_body=0x4009b950 <txn_body_abort_txn>, baton=0x818c290,
> pool=0x8061f38)
> at subversion/libsvn_fs_base/trail.c:291
> #7 0x4009b9f8 in svn_fs_base__abort_txn (txn=0x818c290, pool=0x8061f38)
> at subversion/libsvn_fs_base/revs-txns.c:917
> #8 0x40073509 in svn_fs_abort_txn (txn=0x818c290, pool=0x8061f38)
> at subversion/libsvn_fs/fs-loader.c:416
> #9 0x4006175c in abort_edit (edit_baton=0x817be60, pool=0x8061f38)
> at subversion/libsvn_repos/commit.c:599
It looks like the commit failed before the crash, and the client then
crashed while aborting the commit.
> #10 0x4001d108 in svn_client_commit (commit_info=0xbffff9b4,
> targets=0x8062e20, nonrecursive=0, ctx=0x80625b8, pool=0x8061f38)
> at subversion/libsvn_client/commit.c:1431
> #11 0x0804c0c8 in svn_cl__commit (os=0x8061f70, baton=0xbffffa28,
> ---Type <return> to continue, or q <return> to quit---
> pool=0x8061f38) at subversion/clients/cmdline/commit-cmd.c:94
> #12 0x0804eecd in main (argc=4, argv=0xbffffca4)
> at subversion/clients/cmdline/main.c:1332
> svnadmin recover works, but checking in again fails again.
With the same gdb stack?
> unfortunately the data is company data, so i cant make it available.
>
> what should i try next ? any way to check if the server works - and get
> a coredump out of it (if it crashes)
There is no server, it's the client itself you need to debug. If you
can't do that then you need to provide enough information to allow
someone else to reproduce the problem.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion 1.1.0 checkin crashes - repo needs recovery
Posted by Martin MAURER <ma...@email.de>.
On Thu, 2004-10-21 at 19:48 +0100, Philip Martin wrote:
> Martin MAURER <ma...@email.de> writes:
>
> > On Thu, 2004-10-21 at 19:07 +0100, Philip Martin wrote:
> >>
> >> In my earlier mail I pointed out that something caused the commit to
> >> abort before the crash. It appears you can reproduce the problem, so
> >> you could use gdb to to back up the stack to svn_client_commit and
> >> print *cmt_err.
> > i am willing to do this - but unfortunately i dont know enough about
> > gdb. How do I achieve this ?
> > (esp "backing up the stack to svn_client_commit")
>
> At the (gdb) prompt type "help" for instructions.
>
> Use the command "up" until you get a message like
>
> #12 0x08012345 in svn_client_commit ...
>
> then type "print *cmt_err".
(gdb)
#10 0x4001d108 in svn_client_commit (commit_info=0xbffff994,
targets=0x8062e20, nonrecursive=0, ctx=0x80625b8, pool=0x8061f38)
at subversion/libsvn_client/commit.c:1431
1431 svn_error_clear (editor->abort_edit (edit_baton, pool));
(gdb) print *cmt_err
$1 = {apr_err = 160029,
message = 0x80e9a20 "Berkeley DB error while appending string for
filesystem /home/lonestar/svntest/SVN_DATABASES/db:\nDB_RUNRECOVERY:
Fatal error, run database recovery", child = 0x80e9968, pool =
0x80e9930, file = 0x400a2fc0 "subversion/libsvn_fs_base/bdb/bdb-err.c",
line = 74}
>
> Ideally, you would reproduce the problem in a small repository/working
> copy created from scratch--then you could show it to us. Failing that
> you need to describe the layout of the files/directories in your
there are just a lot of files in the repo root directory.
The files are all SQL Dumps (mysqldump generated)
I cant reproduce this in another repository, as even this repository
worked perfectly up to revision 212. No other known subversion problems
on this machine.
> working copy and the changes you are trying to commit, something like
> "svn status" (perhaps "svn st -uv" as well if it is not too large).
svn diff:
Index: guute_release_price
===================================================================
--- guute_release_price (revision 212)
+++ guute_release_price (working copy)
@@ -1,3 +1,4 @@
+bla
-- MySQL dump 8.21
--
-- Host: localhost Database: guute_release
(only added "bla" before the first line)
greetings
--
Martin MAURER <ma...@email.de>
Re: subversion 1.1.0 checkin crashes - repo needs recovery
Posted by Philip Martin <ph...@codematters.co.uk>.
Martin MAURER <ma...@email.de> writes:
> On Thu, 2004-10-21 at 19:07 +0100, Philip Martin wrote:
>>
>> In my earlier mail I pointed out that something caused the commit to
>> abort before the crash. It appears you can reproduce the problem, so
>> you could use gdb to to back up the stack to svn_client_commit and
>> print *cmt_err.
> i am willing to do this - but unfortunately i dont know enough about
> gdb. How do I achieve this ?
> (esp "backing up the stack to svn_client_commit")
At the (gdb) prompt type "help" for instructions.
Use the command "up" until you get a message like
#12 0x08012345 in svn_client_commit ...
then type "print *cmt_err".
Ideally, you would reproduce the problem in a small repository/working
copy created from scratch--then you could show it to us. Failing that
you need to describe the layout of the files/directories in your
working copy and the changes you are trying to commit, something like
"svn status" (perhaps "svn st -uv" as well if it is not too large).
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion 1.1.0 checkin crashes - repo needs recovery
Posted by Martin MAURER <ma...@email.de>.
On Thu, 2004-10-21 at 19:07 +0100, Philip Martin wrote:
> Martin MAURER <ma...@email.de> writes:
>
> > First of all: the problem is solveable by dumping and loading the
> > repository. So it isnt really an issue for me personally. Just wanted to
> > let you know about this.
> >
> > when i make a checkout and modify any file, then the next checkin fails.
> > so the problem seems to be on the repository side.
>
> The client is crashing while using ra_local, that means the BDB locks
> don't get released.
>
> In my earlier mail I pointed out that something caused the commit to
> abort before the crash. It appears you can reproduce the problem, so
> you could use gdb to to back up the stack to svn_client_commit and
> print *cmt_err.
i am willing to do this - but unfortunately i dont know enough about
gdb. How do I achieve this ?
(esp "backing up the stack to svn_client_commit")
greetings
--
Martin MAURER <ma...@email.de>
Re: subversion 1.1.0 checkin crashes - repo needs recovery
Posted by Philip Martin <ph...@codematters.co.uk>.
Martin MAURER <ma...@email.de> writes:
> First of all: the problem is solveable by dumping and loading the
> repository. So it isnt really an issue for me personally. Just wanted to
> let you know about this.
>
> when i make a checkout and modify any file, then the next checkin fails.
> so the problem seems to be on the repository side.
The client is crashing while using ra_local, that means the BDB locks
don't get released.
In my earlier mail I pointed out that something caused the commit to
abort before the crash. It appears you can reproduce the problem, so
you could use gdb to to back up the stack to svn_client_commit and
print *cmt_err.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion 1.1.0 checkin crashes - repo needs recovery
Posted by Martin MAURER <ma...@email.de>.
Hi, well i did a lot of further tests.
First of all: the problem is solveable by dumping and loading the
repository. So it isnt really an issue for me personally. Just wanted to
let you know about this.
when i make a checkout and modify any file, then the next checkin fails.
so the problem seems to be on the repository side.
i added the output of the permissions of the repo
at the bottom of this mail.
using sudo svn ci doesnt solve the problem. (dont know if it should if
there were permission problems)
i added some some answers below.
any further info you need ?
On Wed, 2004-10-20 at 09:59 -0400, John Peacock wrote:
> Martin MAURER wrote:
>
> > I am using version 1.1.0 with a bdb backend.
> > access method file://
> > Recently when i tried to check in some changes i got a crash.
> > backtrace follows:
>
> Just to clear up a few things before anyone else can dive deeper:
>
> 1) file:// access is primarily useful for single user access; if
> multiple uid's need access to the repository you are much more likely to
> have problems with setting the ownership and umask correctly. svnserve
> is much easier to manage correctly and can be bound to the loopback
> address for additional security.
I use this repository only for a daily backup. it is always the same
user who accesses it.
>
> 2) Just to confirm, BDB files cannot be accessed safely on any networked
> harddrive (e.g. NFS, SAMBA, NT mounts) because of the way that BDB
> manages shared access using a memory mapped region. This is not a
> limitation of FSFS repositories (though there are issues with large
> repository under NTFS, due to the number of files created).
ok. not networked either.
>
> 3) You need to tell us the OS and other information about your environment.
linux
bdb 4.2.52
debian stable, with apache, bdb and subversion compiled from their
sources. apache 2.0.52
"svnadmin, version 1.1.0 (r11180)
compiled Oct 6 2004, 15:32:18"
>
> 4) After checking to see that the file ownership is consistent
> (especially that the log files must be r/w by the user accessing the
> repository, and preferrably owned by that user), did you run
>
> svnadmin recover REPOS_PATH
>
> and what did it say?
Repository lock acquired.
Please wait; recovering the repository may take some time...
Recovery completed.
The latest repos revision is 212.
looks ok for me.
now i add the log of ls -alR REPOS
(REPOS=SVN_DATABASES)
SVN_DATABASES/:
total 36
drwxrwxr-x 7 lonestar lonestar 4096 Mar 2 2004 .
drwxr-sr-x 5 lonestar lonestar 4096 Oct 20 17:32 ..
-rw-rw-r-- 1 lonestar lonestar 376 Mar 2 2004 README.txt
drwxrwxr-x 2 lonestar lonestar 4096 Mar 2 2004 conf
drwxrwxr-x 2 lonestar lonestar 4096 Mar 2 2004 dav
drwxrwxr-x 2 lonestar lonestar 4096 Oct 20 17:52 db
-rw-rw-r-- 1 lonestar lonestar 2 Mar 2 2004 format
drwxrwxr-x 2 lonestar lonestar 4096 Mar 2 2004 hooks
drwxrwxr-x 2 lonestar lonestar 4096 Mar 2 2004 locks
SVN_DATABASES/conf:
total 12
drwxrwxr-x 2 lonestar lonestar 4096 Mar 2 2004 .
drwxrwxr-x 7 lonestar lonestar 4096 Mar 2 2004 ..
-rw-rw-r-- 1 lonestar lonestar 1097 Sep 1 13:40 svnserve.conf
SVN_DATABASES/dav:
total 8
drwxrwxr-x 2 lonestar lonestar 4096 Mar 2 2004 .
drwxrwxr-x 7 lonestar lonestar 4096 Mar 2 2004 ..
SVN_DATABASES/db:
total 158620
drwxrwxr-x 2 lonestar lonestar 4096 Oct 20 17:52 .
drwxrwxr-x 7 lonestar lonestar 4096 Mar 2 2004 ..
-rw-rw-r-- 1 lonestar lonestar 1738 Mar 2 2004 DB_CONFIG
-rw-r--r-- 1 lonestar lonestar 8192 Oct 20 17:52 __db.001
-rw-r--r-- 1 lonestar lonestar 270336 Oct 20 17:52 __db.002
-rw-r--r-- 1 lonestar lonestar 327680 Oct 20 17:52 __db.003
-rw-r--r-- 1 lonestar lonestar 737280 Oct 20 17:52 __db.004
-rw-r--r-- 1 lonestar lonestar 16384 Oct 20 17:52 __db.005
-rw-rw-r-- 1 lonestar lonestar 503808 Oct 20 17:52 changes
-rw-rw-r-- 1 lonestar lonestar 8192 Oct 20 17:52 copies
-rw-rw-rw- 1 lonestar lonestar 1046151 Oct 20 02:03 log.0000002288
-rw-rw-rw- 1 lonestar lonestar 1048320 Oct 20 02:04 log.0000002289
-rw-rw-rw- 1 lonestar lonestar 193693 Oct 20 17:52 log.0000002290
-rw-rw-r-- 1 lonestar lonestar 430080 Oct 20 17:52 nodes
-rw-rw-r-- 1 lonestar lonestar 1568768 Oct 20 17:52 representations
-rw-rw-r-- 1 lonestar lonestar 16384 Oct 20 17:52 revisions
-rw-rw-r-- 1 lonestar lonestar 156635136 Oct 20 17:52 strings
-rw-rw-r-- 1 lonestar lonestar 73728 Oct 20 17:52 transactions
-rw-rw-r-- 1 lonestar lonestar 8192 Oct 20 17:52 uuids
SVN_DATABASES/hooks:
total 28
drwxrwxr-x 2 lonestar lonestar 4096 Mar 2 2004 .
drwxrwxr-x 7 lonestar lonestar 4096 Mar 2 2004 ..
-rw-rw-r-- 1 lonestar lonestar 1411 Mar 2 2004 post-commit.tmpl
-rw-rw-r-- 1 lonestar lonestar 1475 Mar 2 2004
post-revprop-change.tmpl
-rw-rw-r-- 1 lonestar lonestar 2216 Mar 2 2004 pre-commit.tmpl
-rw-rw-r-- 1 lonestar lonestar 1952 Mar 2 2004
pre-revprop-change.tmpl
-rw-rw-r-- 1 lonestar lonestar 1500 Mar 2 2004
start-commit.tmpl
SVN_DATABASES/locks:
total 16
drwxrwxr-x 2 lonestar lonestar 4096 Mar 2 2004 .
drwxrwxr-x 7 lonestar lonestar 4096 Mar 2 2004 ..
-rw-rw-r-- 1 lonestar lonestar 295 Mar 2 2004 db-logs.lock
-rw-rw-r-- 1 lonestar lonestar 460 Mar 2 2004 db.lock
Re: subversion 1.1.0 checkin crashes - repo needs recovery
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> First I can recall hearing of this. What issues are these?
>
> (The only actual, concrete complaint I can remember seeing about FSFS
> storing many rev files in the same directory is that someone's NFS
> backup script became very slow.)
That's what I was referring to. NTFS performance degrades quickly with
multiple 10's of thousands of files in a single directory.
And I have personally noticed that this can happen even if the directory
in question isn't actually accessed directly. For example, we have a
Windows-based web server and we have a folder with lots of shopping cart
files (very small). _Any_ drive access on that volume is slow; I have
no idea why. My WAG is that since NTFS will store the file contents in
the directory table entry if the file contents are smaller than the
blocksize, having lots of small files make the entire directory table
much larger and causes a lot of swapping to handle it. Just typing
"DIR" in a directory several layers above the large folder will take
several minutes to return /any/ information.
I think the last time this came up, I opined that the FSFS design should
have used some form of hashing to store the repository files. Of
course, I didn't offer a patch to do it, so my complaints are largely
theoretical. No offense intended to the basic FSFS design; in my
experience, NTFS has not demonstrated itself to be nearly as robust as
most *nix filesystems.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion 1.1.0 checkin crashes - repo needs recovery
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-10-20 at 09:59, John Peacock wrote:
> (though there are issues with large
> repository under NTFS, due to the number of files created).
First I can recall hearing of this. What issues are these?
(The only actual, concrete complaint I can remember seeing about FSFS
storing many rev files in the same directory is that someone's NFS
backup script became very slow.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion 1.1.0 checkin crashes - repo needs recovery
Posted by John Peacock <jp...@rowman.com>.
Martin MAURER wrote:
> I am using version 1.1.0 with a bdb backend.
> access method file://
> Recently when i tried to check in some changes i got a crash.
> backtrace follows:
Just to clear up a few things before anyone else can dive deeper:
1) file:// access is primarily useful for single user access; if
multiple uid's need access to the repository you are much more likely to
have problems with setting the ownership and umask correctly. svnserve
is much easier to manage correctly and can be bound to the loopback
address for additional security.
2) Just to confirm, BDB files cannot be accessed safely on any networked
harddrive (e.g. NFS, SAMBA, NT mounts) because of the way that BDB
manages shared access using a memory mapped region. This is not a
limitation of FSFS repositories (though there are issues with large
repository under NTFS, due to the number of files created).
3) You need to tell us the OS and other information about your environment.
4) After checking to see that the file ownership is consistent
(especially that the log files must be r/w by the user accessing the
repository, and preferrably owned by that user), did you run
svnadmin recover REPOS_PATH
and what did it say?
HTH
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org