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

Re: a non-atomic svn commit - possible bug?

From: Kirk A. Watrous <kirkwatrous_at_yahoo.com>
Date: 2005-02-15 02:33:46 CET

--- Bryan Donlan <bdonlan@bd.beginyourfear.com> wrote:
> Toby Johnson wrote:
> | Max Bowsher wrote:
> |
> |>> /* tail-end of "svn commit" output below (path names changed) */
> |>> Transmitting file data ..........svn: Commit failed (details
> follow):
> |>> svn: Berkeley DB error while appending string for filesystem
> |>> /path/to/repos/db:
> |>> Not enough space
> |>> svn: bdb: Lock table is out of available locks
> |>> svn: Your commit message was left in a temporary file:
> |>> svn: 'svn-commit.tmp'
> |>> # echo $?
> |>> 1
> |>
> |>
> |>
> |> Sounds to me like the commit was successfully atomically applied,
> but
> |> then an error occurred whilst deltifying old versions of the files
> |> against the new fulltexts.
> |
> |
> | So what exactly does this mean to us non-SVN hackers? Is the
> repository
> | in a usable state at this point? Is this something to watch out
> for? How
> | does one recover from this situation?
>
> I'm not sure, but I think it means the commit did succeed, but some
> internal bookkeeping failed afterward. I'm not sure, but I think this
> will fix it:
>
> * Shut down all accessors
> * svnadmin recover (repo)
> * svnadmin deltify (repo)

I upped the values for set_lk_max_locks, set_lk_max_lockers, and
set_lk_max_objects from the default of 2000 to 5000, but this same
issue happened yet again upon trying to complete another large commit.
There was a slightly different error message this time, but the problem
appears to be basically the same:
/* tail of svn commit error output */
svn: Commit failed (details follow):
svn: Berkeley DB error while reading representation for filesystem
<path_to_repos>/db:
Not enough space
svn: bdb: Lock table is out of available locks
/* end of svn commit error output */

This time, I looked into it a bit more carefully and I don't believe
I'm missing anything in the new revision of the repository, so I think
you are all correct in the assertion that the commit did succeed
completely. So, that means there is at least a problem with svn
giving an incorrect error message, since it did explicitly say "Commit
failed". That is evidently incorrect. Is this a known bug?
The other symptoms of running Berkeley DB out of locks was that
thousands of unused db logs are left in the db sub-directory of the
repository. And, until I run "svn update" for the working copy, "svn
status" after the problem commit incorrectly tells me that my working
copy directory structure is vastly different that that now in the
repository, which is ridiculous since this working copy is precisely
the source whence the current state of the repository in the head
revision came, from this last commit.
Any further thoughts?

Thanks,
Kirk

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 15 18:36:36 2005

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.