Is it possible to get further feedback on this? This issue is still impacting users on a daily basis.
Any help on further diagnosing the issue would also be welcome.
> 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).
> 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).
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2016-06-01 15:31:43 CEST