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

Re: repeated database problems...

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-04-22 21:49:37 CEST

On Thu, 2004-04-22 at 14:34, Perry E. Metzger wrote:
> Okay, based on what you've said, I've found a possible permissions
> problem (see below). However, as a point of principle, the repository
> should really be able to recover itself. If one of my users hits ^C at
> the wrong point, the repo should not get curdled. If the system knows
> enough to know it needs to run recover, it should know enough to lock
> the database and actually run the recover.

This has been the subject of much debate in the past. Originally, we
deliberately decided not to do this, because N different processes could
be accessing the database at any given moment. Running recovery
requires exclusive access, and there's no way for one process to be
aware of all the others.

That was the early days; more recently, our database readers/writers
take out a lock in the repos/locks/ area. If you run 'svnadmin
recover', then in theory, svnadmin waits for all locks to vanish before
running recovery. So I suppose this *could* happen now... we'd need to

Really, this is all the "dark side" of using an embedded database. The
"good side" is that you don't need to set up a whole SQL subsystem to
get database features of your repository. The bad news is that because
there isn't a single process mediating all table access (e.g. something
like mysqld), it's easy for processes to mess things up for each other.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 22 21:52:17 2004

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.