Re: TSVN locking Bug

Hi Ben,
> Appreciate the feedback Stefan but the svn cleanup routine has been attempted multiple times but the lock error still repeated afterwards (i.e. no guarantee that it would stop the lock occurring).
Then I got your colleague slightly wrong. My explanation was for the
case to resolve the issue that you upgraded the TSVN client while having
a WC in a locked state. The steps I provided should have resolved that.
Should have checked Ian's signature, to get the idea that this is
unlikely the case here. :-)

Just to confirm: I get it that this wasn't the problem here - aka: when
you upgraded the TSVN client the WC wasn't in a locked state and after
the upgrade you could successfully upgrade the WC, correct?

So you are rather facing the issue that with the merge operation you
still experience issues with the db being in a locked state, right?

I'll leave the reply about your code investigation to someone else then.
> Some further feedback gained from looking briefly at the TSVN code and observing the merge behavior on a VDI. The locking issue was seen occurring virtually everytime for end-users. Attempted to merge a single file and found that it took 26 seconds for the working copy thread to complete. Once the thread finished, the merge succeeded.
>
> Taking a closer look at the source code:
> - Depending on the choice of the first screen or command line options (revision range, tree, or reintegrate), TSVN will select the corresponding screen based off of the selected option.
> - All three of these screens launch the WC check thread when the screens initialize and stops the thread when the next button is clicked.
>
> When a lock happens, the thread is killed before it runs to completion. Since there is seems to be no cleanup in the thread when it is told to stop, a lingering lock on the wc.db-journal remains until the process (TSVN itself) is terminated. The lock may be from SVN code stopping when writing stuff with SQLite.
>
> Tested using a slightly altered version of TSVN (that was created and compiled) that does not launch the WC thread and was unable to reproduce the lock issue on the VDI when clicking the next button as fast as possible at the root repository level.
>
> Could any of these routes be viable in fixing the issue?
>
> 1. Force the merge to wait until the thread complete.
> 2. Do not fire the WC check thread at all.
> 3. Properly clean up the SQLite data in SVN when told to stop. (I am not sure if this is even possible).

-- 
Regards,
Stefan Hett
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3173278
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].