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

Re: svn.collab.net is now running Subversion 0.23.

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-05-20 08:27:06 CEST

cmpilato@collab.net wrote:

>So, I'm remember how we print error messages, it looks like the
>deadlock happens first, and *then* the "already exists" is tacked onto
> err = svn_fs__bdb_get_node_revision (NULL, fs, new_id, trail);
> if ((! err) || (err->apr_err != SVN_ERR_FS_ID_NOT_FOUND))
> {
> svn_string_t *id_str = svn_fs_unparse_id (id, trail->pool);
> svn_string_t *new_id_str = svn_fs_unparse_id (new_id, trail->pool);
> return svn_error_createf
> "successor id `%s' (for `%s') already exists in filesystem '%s'",
> new_id_str->data, id_str->data, fs->path);
> }
>Ah. So, our error message isn't really all that helpful, since any
>error except "not found" (include "deadlock error") will make it
>appear that there is, to use TuttSpeak :-), a NodeRev PK conflict. I
>remain confident that our filesystem code isn't generating clashing
Right, I was pretty certain of that myself.

>Still, the deadlock concerns me.
Yes. The granularity of our transactions is far, far too large, and we
have absolutely no control over locking order. I'm 99% certain that's
where the deadlock comes from -- we simply don't access the various BDB
tables in a well-known order, and we keep stuff locked longer than

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 20 08:27:55 2003

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.