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?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 17 18:04:01 2002