On Fri, May 17, 2002 at 05:02:37PM +0100, Stephen C. Tweedie wrote:
> On Thu, May 16, 2002 at 01:36:05PM -0500, Karl Fogel wrote:
> > "Sander Striker" <email@example.com> 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
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."
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
Received on Fri May 17 18:12:15 2002
- application/pgp-signature attachment: stored