Georg Wittenburg wrote:
> On Monday 09 May 2005 11:22, John Szakmeister wrote:
>
>>On Monday 09 May 2005 04:13, Georg Wittenburg wrote:
>>
>>>Good morning,
>>>
>>>I switched over from CVS to SVN 1.1.4 about a month ago and have been
>>>accessing my repository using file:/// and svn+ssh:// as one of a group
>>>of two people that have write access. No fancy stuff, imho. While my
>>>last commit before this weekend went in without trouble, now my
>>>repository seems to be corrupt.
>>>
>>>Actually, I already recovered once this Saturday using a procedure I
>>>found online (sorry, no URL) that included rm __db.00*, rm
>>>log.000000001*, db_recover -cv in the db directory. Things worked fine
>>>after that and I was able to commit and update. I do have a backup from
>>>that time, so my data is safe and I'm not in trouble. However, I DO
>>>worry about the reliability of SVN because this morning I got the
>>>following errors (and I don't think my first recovery attempt was
>>>flawed, because things were working fine just afterwards):
>>>
>>>$svn up
>>>svn: Berkeley DB error while checkpointing after Berkeley DB
>>>transaction for filesystem /home/bude/wittenbu/svn/db:
>>>Invalid argument
>>>svn: bdb: DB_ENV->log_flush: LSN of 19/323156 past current end-of-log
>>>of 1/38823
>>>svn: bdb: Database environment corrupt; the wrong log files may have
>>>been removed or incompatible database files imported from another
>>>environment svn: bdb: representations: unable to flush page: 0
>>>svn: bdb: txn_checkpoint: failed to flush the buffer cache Invalid
>>>argument
>>
>>What version of BDB are you using, and have you recently upgraded it at
>>all? Also, does the repository lie on a local filesystem, or are you
>>using it on an remote share of some sort?
>
>
> BDB is version 4.2, to be exact the Debian package is 4.2.52-18. The
> filesystem is mounted over the network, I assume using NFS but autofs won't
> tell me.
And that is the crux of your problem. BDB will not work across a remote
share such as NFS. Let me rephrase that. It will *try* (because it
doesn't know the difference), but it will fail in random ways (as you
saw). FSFS is really the only way to go if your repository must live on
a network share.
[snip]
> Thanks for your encouragement and for all the replies on this list. :)
>
> I've migrated the repository over to FSFS and things seem to work now (link to
> the HOWTO in my previous post).
>
> I have to admit that in retrospect the critical bit of information isn't that
> hard to find: FAQ -> "My repository seems to get stuck..." -> "How do I set
> repository permissions..." -> SVN Book, chapter 6, bottom. Three clicks if
> you know what you're locking for.
>
> As word has it that the problem with BDB will be addressed in the next major
I'm not sure what you're talking about here. Settings have been
tweaked, and I believe we'll print out more helpful error messages, but
I'm not sure what patricular problem you're talking about.
> version, mind if I make a suggestions for the next minor version to allow
> users (who like me prefer not to read the whole 933KB SVN Book, blame me) to
> sort out this stuff by themselves: Make the SVN's error messages a bit more
> descriptive:
While I understand where you're coming from, I'd say that you can't
expect to go and set up something as critical as a version control tool
without reading up on it first. From a business perspective, tools like
this are critical in that they affect everyday operations and they house
a lot of IP. Both of which are key to a successful business. I wouldn't
expect to shove millions of dollars into a database without
understanding all the details (setup, maintenance, etc).
I'm not trying to diminish what you're saying. We should strive to make
things as easy as possible. But I also think that having things run
perfectly right out of the box, and catch every little setup problem, is
a bit pie-in-the-sky.
> - With "svn up" instead of "svn: Berkeley DB error while checkpointing after
> Berkeley DB transaction for filesystem /home/bude/wittenbu/svn/db: Invalid
> argument" add something like "An error occurred probably because of incorrect
> setup. Please have a look at the documentation and run svnadmin
> recover /path/to/repository.".
> - With "svnadmin recover" instead of "svn: DB_RUNRECOVERY: Fatal error, run
> database recovery" add something like "...BUT YOUR DATA IS PROBABLY OK (see
> doc XY for ways to recover manually)." where XY would be a pointer to the
> steps I described in my first mail.
> As my kind of misconfiguration seems to be somewhat common, there's really no
> reason to leave the users out in the dark.
>
> Further, one could argue about whether it would be nice for svnadmin to check
> for proper permission, umask, etc. when working on a repository and display
> warnings even in non-verbose mode.
The problem is having a platform independent way of doing this. I'm not
sure if APR offers all the necessary mechanisms to make this feasible.
> The above is just my two cents to keep other users in the future from worrying
> about their projects early on Monday mornings. :)
Thanks for the suggestions!
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 9 14:49:29 2005