Re: Problems with exclusive-locking

On 27.02.2014 10:04, bugreport wrote:
> Hi folks,
>
> I've just updated to TSVN 1.8.5 recently and the overall impression is very well.
> One of the main reasons for upgrading from 1.7.x is the new exclusive-locking option the subversion 1.8 release notes write about. We are instructed to keep our working-copies on network storage (as building is only available on one special command-line-only machine) and I try to see if/what performance benefits we can see.
>
> For enabling this in TSVN I've added the following part to the subversion config file (opened via TSVN settings dialogue):
>
> # ----------------------------------------
> ### Section for configuring working copies.
> [working-copy]
> ### Set to a list of the names of specific clients that should use
> ### exclusive SQLite locking of working copies. This increases the
> ### performance of the client but prevents concurrent access by
> ### other clients. Third-party clients may also support this
> ### option.
> ### Possible values:
> ### svn (the command line client)
> # exclusive-locking-clients =
> ### Set to true to enable exclusive SQLite locking of working
> ### copies by all clients using the 1.8 APIs. Enabling this may
> ### cause some clients to fail to work properly. This does not have
> ### to be set for exclusive-locking-clients to work.
> exclusive-locking = true
> # ----------------------------------------
>
> I've recognized that with exclusive-locking enabled the working copy is still locked (resulting in sqlite [S5] on command line) after TSVN->update *as long as the update dialogue is open* - **even if the update itself was long finished**.
> I guess TSVN (or at least the code below the update dialogue) does not end/close the API.
>
> Another issue (that would be good to solve first) can be seen if a working copy is locked: the context menu in Windows Explorer does not open at all (only for the locked working copy [and all files in all sub-folders]). Please try to have a "clean" timeout and maybe list something like TSVN (time-out) in context menu for not blocking the context menu.
>
> The commit dialogue (if opened before and is refreshed during lock) reports "there is nothing to do for TSVN", something like "The working-copy is currently locked, please try again later." would be nice in this case.
>
> BTW: Is there an possible entry for "exclusive-locking-clients" that works with TSVN? I've tried TortoiseProc, TortoiseProc.exe, TSVN, svn - none of them worked and I had to enable "exclusive-locking" to use it for TSVN.

Exclusive locking won't work with TSVN.
The only reason to enable this is to get a small performance boost, and
I really mean a small one.

As the SQLite docs mention:
http://sqlite.org/pragma.html#pragma_locking_mode

quote:
There are three reasons to set the locking-mode to EXCLUSIVE.

1. The application wants to prevent other processes from accessing the
database file.
2. The number of system calls for filesystem operations is reduced,
possibly resulting in a small performance increase.
3. WAL databases can be accessed in EXCLUSIVE mode without the use of
shared memory.

So let's check those reasons:
1. No need for that. If an svn client needs to modify the db, then the
db is locked for the write operation anyway. No need to lock the db for
read operations. SVN takes care of multiple accesses properly without
that option.
2. The performance increase on Windows is neglectable, unless your
working copy db is in the GB range. And even with such big dbs, the
performance increase is not that big.
3. doesn't concern SVN clients

So there's no reason to enable this option.

The real problem for you is that you keep working copies on a network
share. That will always be slow. You really should find a way to keep
the working copies local. You can set up your build machine so that it
keeps its own working copy locally and run an 'svn update' before every
build. That's how such things usually are set up to work.

To explain further why exclusive locking does not work with TSVN:
As you have already noticed, the lock is not released until the TSVN
dialogs are closed. That's because of the internal implementation of how
these locks are handled in the svn lib and TSVN. If the command line
client would not quit (i.e., the process ends) after each command, the
lock would be kept there as well.
Which means the TSVN context menu fails to work as long as there's such
a lock, because it has to get the status of the working copy for the
menu items to show.
You've also noticed that if you try to show the context menu that the
explorer basically hangs. That's because there's a big timeout
implemented in the svn lib if there's a lock on a wc database. Because
on a Windows machine, multiple processes access those db files a lot.
And don't forget the TSVNCache process, which scans all working copies
for modifications to keep the overlay icons up to date. With exclusive
locking, you would also have to disable those overlays completely.

Sorry to tell you this, but exclusive locking like this will never work
with TSVN.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3073749
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].