Repository keeps corrupting

Hello all,

I'm new to the list and subscribed to stay up to date on any issues svn
may have. I've got a real love/hate relationship with subversion. I love
it when it works, I hate it when it doesn't. :)

I've only been using it for about a week, but over the last couple days
things have become somewhat messy:

I'm working on a PHP project. Typically I make modifications, save them,
and commit my changes rather often. Because I'm such a forgetful
individual, and because it's neat to see how things evolve, I usually run
"svn diff | less" to see what I modified before committing.

I was running 0.28 at the time and wanted to see how it would work with
multiple users. I didn't keep notes of what exactly happened, but the
first time I tried to access svn with a different user, it corrupted
shortly afterwards.

The first time that happened I was dumbfounded, but simply ran "svnadmin
recover" and it fixed things.

The second time even "svnadmin recover" broke. It just kept telling me to
recover while I was recovering, no matter how often I tried.

Of course I hadn't done a dump yet, which is what I tried next. It dumped
all revisions and then printed "aborted". The dump, however, seemed to be
complete.

So then I upgraded to 0.28.2 just last night, and did a "svnadmin load" of
my "aborted" dump, which I also inspected "by hand". Worked great, no
problems.

I also set up the subversion user's crontab to do a full dump every 3 hours.

Then, today I started working on some more changes. I tried to commit my
changes and here's the output:

$ svn commit -m "listbox can be fed a custom message to display if there
are no rows"
subversion/libsvn_client/commit.c:735: (apr_err=180001)
svn: Couldn't open a repository.
svn: Commit failed (details follow):
subversion/libsvn_ra_local/ra_plugin.c:225: (apr_err=180001)
svn: Unable to open an ra_local session to URL
subversion/libsvn_ra_local/split_url.c:112: (apr_err=180001)
svn: Unable to open repository 'file:///data/repository/dotws/trunk/gbl'
subversion/libsvn_fs/bdb/bdb-err.c:58: (apr_err=160029)
svn: Berkeley DB error
svn: Berkeley DB error while opening environment for filesystem
/data/repository/dotws/db:
DB_RUNRECOVERY: Fatal error, run database recovery

A little annoyed I checked my backups.

-rw-r--r-- 1 svn svn 50660 Sep 2 23:34
dotws-200309022334.svn.bz2
-rw-r--r-- 1 svn svn 51346 Sep 3 04:00
dotws-200309030400.svn.bz2
-rw-r--r-- 1 svn svn 55083 Sep 3 19:52
dotws-200309031952.svn.bz2
-rw-r--r-- 1 svn svn 56375 Sep 3 21:00
dotws-200309032100.svn.bz2
-rw-r--r-- 1 svn svn 56375 Sep 4 00:00
dotws-200309040000.svn.bz2
-rw-r--r-- 1 svn svn 425 Sep 4 03:00
dotws-200309040300.svn.bz2
-rw-r--r-- 1 svn svn 14 Sep 4 06:00
dotws-200309040600.svn.bz2
-rw-r--r-- 1 svn svn 14 Sep 4 09:00
dotws-200309040900.svn.bz2

Apparently it must have corrupted after my last commit.

So I tried to recover the repository:

svn@infinity:~$ svnadmin recover repository/dotws
Acquiring exclusive lock on repository db.
Recovery is running, please stand
by...subversion/libsvn_fs/bdb/bdb-err.c:48: (apr_err=160029)
svn: Berkeley DB error
svn: DB_RUNRECOVERY: Fatal error, run database recovery

With no luck.

Then I checked the mail from the Cron Daemon.

The backup at 0:00 am was complete. All 37 revisions.

The backup at 3:00 am, however, had this output:

--
subversion/svnadmin/main.c:349: (apr_err=205000)
svn: Client error in parsing arguments
svn: first revision cannot be higher than second
--
AND the actual "dotws-200309040300.svn.bz2" created contained
--
dump: usage: svnadmin dump REPOS_PATH [-r LOWER[:UPPER]] [--incremental]
Dump the contents of filesystem to stdout in a 'dumpfile'
portable format, sending feedback to stderr.  Dump revisions
LOWER rev through UPPER rev.  If no revisions are given, dump all
revision trees.  If only LOWER is given, dump that one revision tree. If
--incremental is passed, then the first revision dumped will be a diff
against the previous revision, instead of the usual fulltext.
Valid options:
  -r [--revision] arg      : specify revision number ARG (or X:Y range)
--incremental            : dump incrementally
  -q [--quiet]             : no progress (only errors) to stderr
--
Apparently that took things apart pretty good, because the backups at 6
and 9 am both read:
--
subversion/libsvn_fs/bdb/bdb-err.c:58: (apr_err=160029)
svn: Berkeley DB error
svn: Berkeley DB error while opening environment for filesystem
/home/svn/repository/dotws/db:
DB_RUNRECOVERY: Fatal error, run database recovery
--
the backup script doesn't do anything fancy, it's just a
/usr/local/bin/svnadmin dump ~svn/repository/dotws/ | bzip2 - >
~/dotws-`date +%Y%m%d%H%M`.svn.bz2
Anyway, what I "lost" were revisions 38 and 39 of which both changes were
only ASCII. Revision 37 was actually only adding a bunch of small .gif
files. Coincidence? Probably. But more importantly, revision 37 was done
by a different user, here's the log:
--
$ svn log -r 36:HEAD
------------------------------------------------------------------------
rev 36:  marcus | 2003-09-03 17:08:45 -0400 (Wed, 03 Sep 2003) | 1 line
added more benchmark watchpoints
------------------------------------------------------------------------
rev 37:  dotws | 2003-09-03 20:27:46 -0400 (Wed, 03 Sep 2003) | 1 line
added task icons
------------------------------------------------------------------------
rev 38:  marcus | 2003-09-04 00:13:04 -0400 (Thu, 04 Sep 2003) | 7 lines
added workflow page icons
added contacts page
added contact list stored proc
added benchmark class (should have been added a few revs. back)
added listbox style sheet class
------------------------------------------------------------------------
rev 39:  marcus | 2003-09-04 00:37:30 -0400 (Thu, 04 Sep 2003) | 2 lines
added alternate row color to listbox widget
------------------------------------------------------------------------
--
I'm not sure what to do at this point.
I'll have it create backups every hour, for one.
I'm not sure it matters (I hope it doesn't) but I'm running Debian 3 (with
lots of stuff built from source), kernel 2.4.21, and the /data partition
that my repository is under is using the ext3 file system, running on 2 x
200GB Maxtor IDE drives with Software RAID-1.
I'm accessing the repository via file:// and am starting to wonder whether
there's some sort of problem with locking, or caching or something that
causes the repository to go bad if two different users access it.
the repository is owned by "svn". all users who access the repository are
in the group "svn". i had to "chmod -R g+w" the repository to allow the
users to access it. Maybe that's the problem? I didn't see how else they
could all access it via file://
Sorry for the rant, just trying to be as detailed as possible.
Thanks,
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org