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

RE: Wedged repositories

From: Sander Striker <striker_at_apache.org>
Date: 2002-07-23 01:39:37 CEST

> From: Jim Blandy [mailto:jimb@red-bean.com]
> Sent: 23 July 2002 00:49

> "Sander Striker" <striker@apache.org> writes:
> > It seems that 'db_recover -e' works more often than 'db_recover'. The
> > -e flag is to retain the environment, which could be influenced by
> > DB_CONFIG. So, we need to remove the DB_PRIVATE flag from the recover
> > routine in repos.c
>
> This doesn't jibe with the Berkeley DB docs, though:
>
> http://www.sleepycat.com/docs/api_c/env_open.html
>
> If we've made sure we're the only process accessing the DB
> environment, it shouldn't matter. We should be able to let the
> recovery process do whatever it pleases. If it doesn't work, then we
> don't really understand what's happening.
>
> I'd like to have a solid explanation for what's going before we start
> flipping flags on and off based on what "works more often." These are
> the repository's low-level mechanisms we're dealing with here; we
> really should try to understand what we're doing.

I agree with you. My post should have been a little lighter on words:
"we might need to remove...".

Anyhow, I'm CC'ing in Keith Bostic (Hi Keith, hope you don't mind),
hoping he can shed some light on this*.

Keith: for the record, one of my repositories locked up one day.
First I tried to run 'dbrecover -v -h ${REPOS}/db'. This didn't
unlock my repos. Then I tried 'dbrecover -ve -h ${REPOS}/db' and
it did unlock my repos. Any ideas?

Sander

*) this being this particular thread.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 23 01:30: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.