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


From: <kfogel_at_collab.net>
Date: 2004-04-27 17:40:39 CEST

"Alison Jones" <Alison.Jones@calrec.com> writes:
> This morning the database crashed with a Fatal error.
> I stopped the svnserve and ran
> z:\r&d\data\repos>svnadmin recover swrepos
> Please wait; recovering the repository may take some time...
> svn: DB_RUNRECOVERY: Fatal error, run database recovery
> I could not recover the database, so moved it out the way and
> restored last nights backup.
> I am using V1.0 of subversion on an windows server, access is
> through svnserve.
> How can I track down what has gone wrong?
> As commits happened this morning the revision has moved up, so now
> when clients try to update they get an error about the revision
> number not existing in the repository. How can I get around this so
> they can re-commit their work.

Next time, don't wipe out your existing repository and restore from a
backup. Instead, run database recovery on the existing repository:


We don't know what caused the fatal error (we'd need much more
information to figure that out), but the DB_RUNRECOVERY error is
well-understood and does not usually represent a serious problem,
although I'll grant it is certainly annoying. Your repository is not
corrupt, it's just wedged, and it can be unwedged.

Now whether you restore the old working copy or not, you'll have
problems, because some working copies have forked from the new repos,
while some are still stuck on the old. There's nothing you can do
now, except choose one way or the other and tell everyone to check out


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 27 18:53:26 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.