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

On Tuesday, May 20, 2003, at 02:40 PM, cmpilato@collab.net wrote:

> =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu> writes:
>
>> Branko ÄŒibej wrote:
>>
>>> I now have stress.pl running on Windows

>> svn: Berkeley DB deadlock error
>> svn: Berkeley DB error while reading node revision for filesystem
>> r://repostress/db:
>> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock
>> svn st -u wcstress.3768: failed: 256
>
> So, I'm remember how we print error messages, it looks like the
> deadlock happens first, and *then* the "already exists" is tacked onto
> it.

[snip part about "already exists" being bogus]

> Still, the deadlock concerns me.

Deadlocks are to be expected, I think. You either:

i) Avoid deadlock by using one big lock. This is inefficient.
ii) Avoid deadlock by making sure you always acquire locks in the same
order, and release them in reverse order. This might be possible if
you made sure that paths were accessed in sorted order. I don't really
know how this works with the subversion schema and BDB transactions
though. I think the lazy copies make this impossible.
iii) Don't avoid deadlock, but deal with it seamlessly. When you get a
deadlock, one of the deadlocked transactions is aborted. You should be
able to redo the command though, and I would have thought that svn
should do this automatically. When restarted, the command should
succeed (the other transaction in the deadlock should have completed).
One detail is that when you restart a commit you may find you are no
longer up to date and so abort for that reason.

Will :-}

--
Dr William Uther                            National ICT Australia
Phone: +61 2 9385 6926             School of Computer Science and 
Engineering
Email: willu@cse.unsw.edu.au             University of New South Wales
Jabber: willu@jabber.cse.unsw.edu.au          Sydney, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org