Repository keeps corrupting
From: Marcus Welz <marcus_at_lucidix.com>
Date: 2003-09-04 17:55:46 CEST
Hello all,
I'm new to the list and subscribed to stay up to date on any issues svn
I've only been using it for about a week, but over the last couple days
I'm working on a PHP project. Typically I make modifications, save them,
I was running 0.28 at the time and wanted to see how it would work with
The first time that happened I was dumbfounded, but simply ran "svnadmin
The second time even "svnadmin recover" broke. It just kept telling me to
Of course I hadn't done a dump yet, which is what I tried next. It dumped
So then I upgraded to 0.28.2 just last night, and did a "svnadmin load" of
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
$ svn commit -m "listbox can be fed a custom message to display if there
A little annoyed I checked my backups.
-rw-r--r-- 1 svn svn 50660 Sep 2 23:34
Apparently it must have corrupted after my last commit.
So I tried to recover the repository:
svn@infinity:~$ svnadmin recover repository/dotws
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.orgReceived on Thu Sep 4 18:17:32 2003 |
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.