[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: database destroyed

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-11-27 01:35:30 CET

Petr Sebor <petr@scssoft.com> writes:

> When (just by accident) someone operates with the database - co/up, while
> dumping the database, it somehow gets always corrupt (so I have to run
> db_recover on it) or worse, the db/__db.001 ... 005 simply just disappear.
> The only cure I know is to svnadmin load the dump back in to regain
> working repository :-(

That makes no sense... the db files *disappear*? Dumping the database
is just another process that is reading data via libsvn_fs. We should
have no problem with concurrent db readers. In fact, we expect
multiple httpd child processes to do this all the time.

>
> and I am really not sure, why the 'svnadmin dump' needs RW access to
> the database?

This is how Berkeley DB works -- even when reading, a lockfile is
still created in the repository.

My only thought is that perhaps there is a clash in permissions. That
is, your 'svnadmin dump' process is running as one user, and the 'svn
co' process is running as different user. I don't know how this would
cause db files to vanish, though.

Can you give us a simple reproduction recipe? Just try dumping during
a checkout? Which process should start first? Which process should
end first?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 27 01:38:47 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.