RE: Re: Problems with exclusive-locking

Hi Stefan, thank you for your reply.

To the performance increase Apache seems to have different test results:

> The only reason to enable this is to get a small performance boost, and
> I really mean a small one.
>
> [...]
>
> 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.

Hm, quote from http://subversion.apache.org/docs/release-notes/1.8.html#exclusivelocking

> Exclusive SQLite locking of working copies
>
> In the root of every Subversion working copy there is an SQLite database in the .svn directory and Subversion clients use this database when accessing the working copy. By default Subversion uses shared SQLite locking and this allows simultaneous access to the working copy by multiple clients with exclusive locks only being held for short periods.
>
> [...]
>
> This reduces the locking overhead but does mean that only one Subversion client will be able to access the working copy at a time. A second client attempting to access a locked working copy will block for 10 seconds and then get an error. In most cases shared locking is preferred but if the working copy is on a network disk rather than a local disk the locking overhead is more significant. When dealing with large working copies on network disks exclusive locking may give a significant performance gain, two or three times faster in some cases.

Why do you think does Apache put this into it's release note, proclaiming a significant performance gain?

I'm aware that placing working copies on network drives (in our case a SAMBA net share) is not the way it should be done, but I'm not in the position to change this internal order. The svn commit/svn update procedure for getting this on the build machine would result in the need for every developer having an own branch as trunk, where current commits go, is near-to-clean and always has significant tests before it's updated - and you need to compile it (only possible on the build machine) before you can test it or get a compiler error...
Therefore this is not possible and even destroys the last bit of sense in the current compile/test procedure.

Thank you for the explanations why exclusive locking currently does not work with TSVN.

These are my open questions, that are open even with the background that TSVN will not support exclusive locking:

1. Is it possible (in a later release) to somehow *end* the current svn command (and therefore the log) without exiting the TSVN process handling the update dialogue? This question comes to mind especially as it works in the commit dialogue, locking only as long as there is a refresh.

2. Can the timeout for the context menu be set (and reduced) by TSVN [maybe set via TSVN->settings or svn config file]? The timeout occurs much faster when using the command line tools.

3. Can TSVN react *clean* on this timeout in the following scenarios:
3.1 Context menu, leading to a TSVN entry that is disabled, empty, or otherwise (with the aim not slow down the Explorer).
3.2 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.

Thank you for answering these points.

BTW: It's nice that the Overlays work quite well with exclusive-locking enabled. But the overlays are very likely the reason why there was a random sqlite[s5] two times on TSVN->update.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3073782

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2014-02-28 08:02:48 CET