1

I have a Windows 7 PC with the latest TortoiseSVN version (1.11.0 x64). Almost every time I want to commit changes to the server, I get the following error:

Commit failed (details follow):
Failed to load properties: sqlite[S5]: database is locked
Error unlocking locked dirs (details follow): sqlite[S5]: database is locked

Another process is blocking the working copy database, or the underlying filesystem does
not support file locking; if the working copy is on a network filesystem, make sure file
locking has been enabled on the file server.

It's easy to fix - I just go to the project root folder, do an SVN cleanup, and then the commit works fine. However, if I want to commit again a few minutes after that, it will most likely fail again and force me to do another cleanup. It gets really annoying.

Is there any way I can prevent these locks from happening? Any settings I can change on TortoiseSVN, or something?

A few more details:

  • Both my SVN projects and TortoiseSVN itself are placed in my local HDD (no network filesystem), and their folders are excluded from the antivirus software.
  • The working copy folder is not network shared (nor locally, I'm the only user on that PC).
  • I don't have Dropbox, Google Drive or any other cloud software sync'ing the folder, either.
  • It's specific to TortoiseSVN, I never get this error when I commit my changes from Eclipse.
  • I really don't think it's a TortoiseSVN bug though, I recently updated from version 1.9.6 to 1.11.0 and both had the same issue, if this really was a bug it surely would have been fixed... right? :)
  • I'm the only developer currently working with the projects (it's not an issue of my local database being out of date, or existing conflicts).
AJPerez
  • 3,435
  • 10
  • 61
  • 91
  • 1
    The working copy is on a network share, is it? – bahrep Nov 09 '18 at 19:27
  • I wish, at least it would explain the problem! But no, the folder is not network shared, and I'm the only user with local access to the computer. Also, now that I think of it... I don't have Dropbox, Google Drive or any other software sync'ing the folder. I'll update the question – AJPerez Nov 09 '18 at 20:12

2 Answers2

1

I also think the lock is caused by eclipse plugin. Here some more details about my setup and how I got rid of the problem:

Tortoise: TortoiseSVN 1.12.2, Build 28653 - 64 Bit , 2019/08/04 13:03:09

Subversion: Subversion 1.12.2, -release

Eclipse: Spring Tool Suite Version: 3.9.6.RELEASE (eclipse Eclipse 2018-09 (4.9.0))

SVN-Plugins in eclipse:

  • Subversive Revision Graph (Optional) 4.0.0.I20160226-1700
  • Subversive SVN Connectors 6.0.4.I20161211-1700
  • Subversive SVN Team Provider 4.0.5.I20170425-1700
  • SVNKit 1.8.14 Implementation (Optional) 6.0.4.I20161211-1700
  • Subversive SVN Integration for the M2E Project (Optional) 4.0.0.I20160226-1700

After de-installing the last (optional) plugin ("Subversive SVN Integration for the M2E Project") the lock on explorer's tortoise didn't occure anymore.

So I am happy because all functionality I use within eclipse still works, and tortoise in explorer works also. Usually I only use the "team/show annotation" context menu in eclipse, all other SVN stuff I do in explorer through tortoise.

Heri
  • 4,368
  • 1
  • 31
  • 51
  • I have uninstalled that plugin, but the problem hasn't gone away for me. Thanks for trying to help, anyway :) – AJPerez Nov 05 '19 at 09:02
  • Yes, sometimes the lock still occurs. But most of the time it works. – Heri Nov 06 '19 at 07:52
  • Some more insights: After working a while with above setup, I encounter the lock only after a tree change, i.e. new, deleted or renamed files/folders. If the commit contains only changes in already existing files, the lock does not occur. – Heri Dec 03 '19 at 10:15
0

Edit: the problem wasn't actually caused by Eclipse itself. It was either the Subversive plugin, or the SVNKit connector. I've switched to Subclipse and JavaHL, and the problem has completely disappeared. I haven't tried with Subclipse+SVNKit, nor Subversive+JavaHL, I guess one of these combinations will solve the problem too, and the other won't.

It seems that the problem is caused by Eclipse. We usually structure our SVN projects like this:

/trunk
  /docs
  /etc
  /scripts
  /source
    /pom.xml
    /src/main/...

I checkout the whole trunk (or some branch), and then import the source projects into Eclipse.

To manage code changes, I use the SVN sync view in Eclipse, which is more user-friendly (just my opinion) than TortoiseSVN. For changes outside the /source folder I have to use TortoiseSVN, since the files aren't in Eclipse.

The problem is that apparently, Eclipse has some background process which "updates the SVN cache" every few minutes, even if you didn't change anything on that project, just by having it open in the workspace. And it messes up TortoiseSVN, hence the errors unless I perform a cleanup.

There is an option in Eclipse, under Team > SVN > Performance, which allows to disable the SVN status cache... but the last time I tried, it didn't prevent the issue, it only made Eclipse SVN sync slower.

I guess my only choices here are to use different checkout folders for Eclipse and TortoiseSVN (ugh...), or to disable SVN in Eclipse and use always TortoiseSVN (ugh...).

AJPerez
  • 3,435
  • 10
  • 61
  • 91