Working copy locked error in tortoise svn while committing

No problem... try this:

Go to top level SVN folder.

Right click on folder (that has your svn files) > TortoiseSVN > CleanUp

This will surely solve your problem. I did this lots of time... :)

Note. Make sure "Break locks" option is selected in the Cleanup dialog.

The accepted answer didn't work for me. To fix that issue, I had to right-click on the file that was locked, select repo-browser. This opened a popup with the files as they are on the SVN server. I then right-clicked on the locked file and selected break lock.

When I closed the repository browser, back on explorer I could finally commit!

Right click on folder. TortoiseSVN->Check for modifications. Click on the Check repository button. Break lock on all files returned.

I ran into this issue as well. For some I would like to point out that if it is locked CHECK WITH YOUR TEAM. Someone on the team might have some things locked because they are working on it (this allows developers to do work on things without others coming in and trying to work on the same content as well). If that is the case, releasing the lock and then updating has the potential to lose data for the developer who locked it.

With that in mind my concern was that the "clean up" option would possibly change my working copy or remove information from the Repo level of Subversion. That is not the case. The answer worked for me. Mine became locked when I clicked cancel during the middle of an update. I ended up pulling some of our branches and I did not need the stuff so I hit cancel. My working copy became locked. I could not find any documents that came up as "locked" when I used the command 'release lock'. This left me puzzled and upon some quick reading (and this thread) I attempted the 'clean up' command. After a clean up it resolved my issue and nothing was locked anymore.

source: http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-locking.html

There are multiple meanings of "lock" in SVN and some of these answers that talk about "break lock" or a teammate holding a lock are not using the relevant meaning for the original question. This question is dealing with "working copy locks" (i.e. they are entirely local to the working copy on your computer and have nothing to do with you or teammates holding a lock/check-out on a file). The accepted answer by MicroEyes is referring to the correct usage and is your best option when this happens.

If a cleanup doesn't work you may need to check out a fresh working copy of the project. If you have any modified, un-commited files you will need to copy them over to the fresh working copy so you don't lose your changes.

See this page in the Tortoise SVN docs for a description of the three usages of "lock": http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-locking.html

Excerpt (emphasis added):

The Three Meanings of “Lock” In this section, and almost everywhere in this book, the words “lock” and “locking” describe a mechanism for mutual exclusion between users to avoid clashing commits. Unfortunately, there are two other sorts of “lock” with which Subversion, and therefore this book, sometimes needs to be concerned. The second is working copy locks, used internally by Subversion to prevent clashes between multiple Subversion clients operating on the same working copy. Usually you get these locks whenever a command like update/commit/... is interrupted due to an error. These locks can be removed by running the cleanup command on the working copy, as described in the section called “Cleanup”. ...

I had no idea what file was having the lock so what I did to get out of this issue was:

Went to the highest level folder Click clean-up and also ticked from the cleaning-up methods --> Break locks

This worked for me.

I had tried various things, including "Clean Up" on lower subdirectories. Finally, I tried updating the top level folder. Nothing. Then I read the "Clean up top level" tip. I tried that. The clean up part succeeded, but the lock remained. My solution was to go back to the top level, clean up, then clean up each red (!) folder I could drill down to. After all was "Cleaned up", the update worked perfectly. The "break lock" tip looks good, too, with the exception that someone on your team might have a legitimate lock on things.

I managed to lock myself out of a file in svn - don't know how - but when I tried (re)-getting the lock (Tortoise was showing the "Get Lock" option for the file), it complained that already had the lock. I tried deleting the file and committing the directory change - same result. I tried CleanUp (including refreshing the overlay), but that failed too.

The solution was to go into the Tortoise repo-browser, find the file and use the break lock function.

If this (https://stackoverflow.com/a/11764922/3045875) does not help: Check if another SVN tool is interfering and close the tool. We just struggled a couple of hours at merging using TortoiseSVN and had dozens of such lock errors. Eventually we figured that Matlabs SVN integration is interfering and after closing it all worked out.

Windows Solution:

https://sourceforge.net/projects/win32svn/

1.Download it, then add it to system path.

2.Go to work directory execute "svn clean" and "svn update" in cmd.