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

Re: DB_CONFIG on svn.collab.net

From: Kevin Pilch-Bisson <kevin_at_pilch-bisson.net>
Date: 2002-05-17 18:10:39 CEST

On Fri, May 17, 2002 at 05:02:37PM +0100, Stephen C. Tweedie wrote:
> Hi,
> On Thu, May 16, 2002 at 01:36:05PM -0500, Karl Fogel wrote:
> > "Sander Striker" <striker@apache.org> writes:
> > > That made me think about a DB_CONFIG in our db environment
> > > in the svn repos on svn.collab.net. Since the defaults
> > > are all set to 1000, maybe doubling makes sense:
> >
> > Well, I read http://www.sleepycat.com/docs/ref/lock/max.html, and came
> > away with appx 5% more understanding than I had before :-).
> >
> > I upped them to 2000 in our fs initialization code (see rev 1971);
> > haven't changed the svn.collab.net repository, as it will get upgraded
> > before long anyway.
> At the very least, would it be possible to add some form of error
> flagging so that when the lock limit is exceeded, we get a useful
> error back instead of the current "out of memory" error that the user
> sees?

That's a good point. Where do you think such an error flag should go? It's
not clear to me whether or not we could actually check db4 for this error
specifically, but we could maybe make a FAQ saying "If you see ENOMEM errs,
try this before giving up...
> Trying to import a kernel tree was repeatedly giving me this error.
> Even once it was pointed out that this was a lock error, not really
> ENOMEM, all that my reading of all the relevant svn and db4
> documentation revealed was the setting of new values in DB_CONFIG.
> That did not fix the problem --- there's a magic db4_recover(8)
> invocation required before the database's locks are expanded.
> In other words, the current error is incredibly misleading, and the
> cure is documented only in the subtle depths of mailing archives as
> far as I can see. It's going to be a common problem for svn users,
> and the current impression people will take away from it is "oh,
> subversion just falls apart on large repositories."
> Cheers,
> Stephen

Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall

  • application/pgp-signature attachment: stored
Received on Fri May 17 18:12:15 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.