Re: TSVN locking Bug

非常感谢您的回复。（Thank you very much for your reply.）
但是我英文超级烂。（But my English is so poor......）
我需要花时间去翻译您的邮件。（I will spend time to translate the E-mail.）
并按照其中的方法进行尝试。（and then follow your steps .）

I'm so sorry.

--
Best Regards,
------------------ Original ------------------
From:  "Stefan Hett";<stefan_at_egosoft.com>;
Date:  Tue, May 24, 2016 03:08 PM
To:  "users"<users_at_tortoisesvn.tigris.org>; 
Subject:  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=3173281
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].