Kirk A. Watrous wrote:
> The following issue happened when trying to commit changes to a large
> repository on local disk. After several hours of svn working (most of
> which were spent in the stage "Transmitting file data .........."), it
> finally *seemed* to fail with the error message below. However,
> although one would expect the commit not to have taken, it actually did
> increment the revision number and add several GB of data to the
> repository. I ran 'svn recover' on it and it stayed at this new
> revision number. However, I think only most, but not all, of the data
> that should have gotten imported during this committal, in fact was.
> For the bdb error message, I assume that the Berkeley DB configuration
> needs to be tuned to increase the maximum number of locks. Regardless
> of whatever that issue happens to be, it is troubling that svn seems to
> have commited anything at all. I thought all commits were suppposed to
> be atomic, no? Also, svn errors out telling me my commit message is in
> a temporary file as would be expected for a failed commit, yet this
> same log message actually *did* make it into the repository as the log
> message for the new revision svn generated (along with a few GB of new
> data). Does anyone know what might be going on here?
>
> /* 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.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 7 10:29:29 2005