SVN frequently says file is locked by me in another working copy

Question

I have an SVN repository (hosted on Dreamhost) with needs-lock set on binary files. It sometimes happen that, while committing files locked and modified by me, the commit fails with the error:

Error: Commit failed (details follow):
Error: File '/my/file.bin' is locked in
Error:  another working copy

If I try to get the lock on that file (without stealing it) it says:

Error: Path '/my/file.bin' is already locked by user
Error:  'my_username' in filesystem '/home/user1/svn/repo1/db'

Cleanup doesn't help, so the only way to solve this is to steal the lock, and then the commit succeedes.

This is not a critical issue, but it is really annoying, especially when it happens in the middle of a long commit. I am inclined to think that this is caused by a bug of the client or the server, since I am sure that I'm not using other working copies, and the issue happens fairly frequently (3 times in the last two days) to me and my colleagues using the repository.

We are using TortoiseSVN 1.8.4, while the Dreamhost svn server is 1.6.12.

Thanks for any help.

UPDATE: I noticed that the error happens if I do an update of my working copy before committing (which gives no error and of course does not modify the locked files). By checking the status of the file, before the update tortoise says it is locked by me (checking only locally), while after the update checking locally it gives "????" as locking state, and by checking the server it then says it is locked by me. After the update the file is made read-only (because of the needs-lock), even if it is still marked as modified. So the sequence of actions is: lock file.bin -> modify file.bin -> update the whole working copy -> commit -> commit failed error. After the update the working copy seems to forget the state of the lock, and when it asks the server it believes it is locked on another working copy.

Ancillary

Answer 1

On Windows, I fixed the problem by the following steps: 1. Launch Repository Browser by clicking "Repo-browser" in the menu. 2. Locate the locked file. 3. Right click your mouse on the locked file. 4. Click "break lock".

Slipperwort

Answer 2

Cleanup will not help. That's used for working copy locks, whereas you're running into an issue with files being locked in the repository itself as a means of implementing a mutex between users. See The Three Meanings of "Lock"

You probably have a client that's locking the file(s) for you in a different working copy without your knowledge (either locally or in a WC on your server), or perhaps you've got a WebDAV share that you've mounted and are opening the file(s) there which is causing a lock to be created.

Moshemoshell

Thank you for the quick answer, I will check the possible problems you pointed out. However, I want to clarify that the issue only happens after I succesfully acquire a lock on a file. The typical sequence of actions leading to the error is, e.g.: lock file.bin -> modify file.bin -> commit file.bin -> commit failed error – Ancillary

I would question whether your working copy is properly recording the lock. What happens when you run svn status after taking the lock? Do you get any error messages when obtaining the lock? – Moshemoshell

I don't get any error other than the "already locked" on commit. On the server we only have trac which uses the repository, we'll try to disable it. Anyway I found out that the error seems to happen only after an update (please see the original question update). – Ancillary

That really sounds like you've got corruption somewhere. Have you run svnadmin verify on the repository & tried a fresh working copy checkout? – Moshemoshell

Answer 3

I also encountered the same problem and found that out of three machines, in one of the machine I have locked the file and due to which I also facing the problem. What I did is release the lock from that machine and proceed further.

OR

Steal the lock first and then start working as this is the best option provided by SVN.

Forrestforrester

Answer 4

If using a JetBrains IDE:

right click on the file you want to unlock, go to Subversion and click lock

then select checkbox steal existing lock and apply with OK

right click on that file again, go to Subversion and click unlock

If using command line:

lock the file with --force

svn lock --force path/to/file.ext

and unlock it again

svn unlock path/to/file.ext

Miler

Answer 5

Found this: https://groups.google.com/forum/#!topic/subversion_users/wZikmNEubz4 It seems this problem manifests when using an svn 1.8 client and a server prior to 1.6.17: when updating the root folder of a working copy, my locks get broken (regardless of the needs-lock flag).

I downgraded to a 1.7.14 client and the problem does not occur.

Ancillary