Working copy XXX locked and cleanup failed in SVN

Question

I get this error when I do an svn update:

Working copy XXXXXXXX locked Please execute "Cleanup" command

When I run cleanup, I get

Cleanup failed to process the following paths: XXXXXXXX

How do I get out of this loop?

Krill

I got this message, too. The answers provided looked a little tedious (especially the highest-voted one). I just closed down VS and reoprned the solution and I was able to check everything in just fine. – Haley

Following eakkas comment to delete entries from WORK_QUEUE table using Firefox's SQLLite Manager fixed the issue for me. – Gasometry

There is a simple answer, just check the option, "break locks" and that will clean up your working copy – Schweiz

I am not even getting the option for break locks – Kragh

My problem was that I was out of space on my machine, which I discovered while trying to implement several of the listed solutions. Identical symptoms but completely different reason. – Disobedient

Answer 1

One approach would be to:

1. Copy edited items to another location.
2. Delete the folder containing the problem path.
3. Update the containing folder through Subversion.
4. Copy your files back or merge changes as needed.
5. Commit

Another option would be to delete the top level folder and check out again. Hopefully it doesn't come to that though.

Homotaxis

+1 to you for this workaround to fix not just the OP's problem (and mine), but also for giving the 5 steps that seem to fix any svn problem. -1 to subversion for needed such workarounds. – Threequarter

While this technically works, it is such a bad way to do this compared to removing the locks that it deserves a downvote. – Insincerity

@Jukka This problem occurs because your repository is in an inconsistent state. It seems safer to me to start clean and revert or update using the tool that manages those files itself to resolve the problem. Admittedly, this takes a few extra steps. – Homotaxis

what about the current version of SVN, there is just one .svn dir, and it does not contain any lock file. I got the problem after svn crashed, now i can't even run an update – Policlinic

I cannot do step 3 because... "Working copy is already locked" – Infante

Consider the advice from BradS "For me, the trick was to run 'svn cleanup' at the top of my working copy, not in the folder where I'd been working the whole time before the problem occurred." – Dowable

@JukkaDahlbom Actually that's not true. This error message came to me when my file was NOT locked. I even locked and unlocked, it kept occurring. – Frymire

This approach works. Specifically in my case, an "svn move" went wrong. I deleted the folder that I attempted to move. I ran "svn cleanup". Then I could run "svn update". I got my folder back and no locks. – Stpierre

Before do this consider the advice from @BradS! – Mangum

For those using Tortoise SVN, you can run clean up on the root folder of the check-out directory and force Break Locks. Additionally you can ask it to delete unversioned files. Then take an update. – Twister

SVN may try to delete or move a used file. Be sure you have not open the IDE or run the build. – Mellar

Answer 2

For me, the trick was to run svn cleanup at the top of my working copy, not in the folder where I'd been working the whole time before the problem occurred.

Testify

usually works but doesn't anymore, not sure if it's because I upgraded to SVN 1.7 – Histoid

this worked for me with a client running 1.7, though the server is still 1.6.x – Meade

Worked for me on 1.7 much appreciated – Robbins

I have combined the hint from Intu's answer with this one: look for the parent folder which has a "lock" file in its .svn folder, then run "svn cleanup" there. That worked for me. – Javanese

+1 This works for me (from about: Tortoise SVN 1.7.7 64 bit / Subversion 1.7.5) – Uziel

Yes, in 1.7 it cleanup has to be performed on top level directory of the working copy, Thank you. – Swathe

I ran a cleanup on the topmost folder and the unlock issue was resolved and I was able to checkin again. – Cogen

Using Subversion for Mac, select 'Clean' from the Working Copy menu. – Am

This works for me, much faster way than Chuck's way. So it's worth a shot to do this one first. – Frymire

Works for me - svn 1.7.17. luv u (hug)(kiss) – Almemar

This was what worked for me; TortoiseSVN (via SVN 1.8.10) was just telling me "cleanup failed, run cleanup." Hitting the command line at the root of the repo told me "Can't remove directory..." etc., which pointed me to the actual problem. Unlocker run on that directory let me detach handles to it and then I reran cleanup and ... it seems like it's working. – Prink

Answer 3

Look in your .svn folder, there will be a file in it called lock. Delete that file and you will be able to update. There may be more lock files in the .svn directory of each subdirectory. They will need deleting also. This could be done as a batch quite simply from the command line with e.g.

find . -name 'lock' -exec rm -v {} \;

Note that you are manually editing files in the .svn folder. They have been put there for a reason. That reason might be a mistake, but if not you could be damaging your local copy.

SOURCE : http://www.svnforum.org/2017/viewtopic.php?p=6068

Platina

+1 I think this is much better approach than the currently highest voted answer - I hate having to copy the files elsewhere first to get around this (common!) problem. Mine was caused by a code-generation tool generating files with the same name that someone else had already added to SVN. My bad for not "svn up" first i suppose... – Tracheitis

nice one, thanks a lot. To help you find the lock file if you are on a terminal type [find . -name "lock"] without the square brackets in your applications directory. – Jocelynjocelyne

This doesn't work anymore with Tortoise/SVN 1.7 (or at least I couldn't find any lock file as there is now a centralised DB with the metadata). – Scrawny

here's a quick one-liner that should recursively delete all locks starting in the current directory: find . | grep ".svn/lock" | xargs rm – Infinite

With SVN 1.7, @BradS's answer seems more effective. This answer did not work for me, and BradS's did. – Tetrode

note that the lock file maybe in a parent directory, svn told me at least which directory – Iaria

In my case there is no lock file anywhere to be found. – Lapse

Source link was dead. – Lilybel

Answer 4

Easiest way ever:

1. Go to Parent directory(Folder) of Project.
2. Pres Right click
3. Press on TortoiseSVN then Press Clean up...
4. Clean up dialog would appear automatically
5. Select Clean up working copy status, Break locks, Fix time stamps, Vacuum pristine copies, Refresh shell overlays, Include externals
6. Pres OK

You did your job successfully.

Check the screen shots for your reference.

First step:

Second step: Enable the Break lock option(second check box in cleanup popup window)

Hope this will help you a lot.

Reorder

in my case, the "Break lock" option was sufficient, maybe try first with this one only – Derm

Good answer. I had a case of 'dialog blindness' with this one and never checked the clean up options. Historically, the 'navigate to root and clean up' used to work but I guess breaking the locks was sufficient in my case.. – Amphimacer

Worked for me too! – Cornetist

Did not think 'break locks' would do it, because I did not make any locks. But apparently it breaks svn-internal locks which were causing this problem. Thanks! – Hypercritical

this works 2023 – Numen

this works, had couple of locked directories. I had to clean up them separately instead of clean up the root directory – Sophist

Answer 5

In my case I solved it by manually deleting a record in the SQLite ".svn\wc" file lock record in the WC_LOCK table.

I opened the "WC" file with SQLite editor and executed

delete from WC_LOCK

Following eakkas's comment, you might need to delete all the entries from WORK_QUEUE table as well.

Linetta

This worked for me for Subversion 1.7.5 on Windows. Downloaded SQLite Expert trial version from here: sqliteexpert.com/download.html. Ran the "delete" sql statement above in the SQL tab. – Rosenblum

This is much much better, just one difference is that I clicked the red (-) button – Rozier

A free DI SQL Spy would also do the trick: yunqa.de/delphi/doku.php/products/sqlitespy/index – Linetta

This worked for me too but I also needed to purge the entries in WORK_QUEUE table – Isabea

Did not work by deleting the item out of WC_LOCK - what did work was looking at the blob contents of my WORK_QUEUE item and sure enough it was the issue file - I removed the file from the repo browser and then deleted the work_queue item - after this ran a cleanup and back in business! – Griffon

For me the file was .svn/wc.db. I had to delete the problem entry from the WORK_QUEUE – Stultz

This was the only thing that worked out of all suggestions. Should be a "clear locks"-function. Used the free SQLite Browser sourceforge.net/projects/sqlitebrowser – Normandnormandy

Don't forget (especially if you're used to working in something like MySQL/MSSQL!) that you need to SAVE changes to the database before you can see the effect of your SQL command(s). (At least using v3.7 of the SQL Lite Browser - sqlitebrowser.org). – Principled

Worked for me. All files in the working copy were showing a "L" in the third column (locked) but TortoiseSVN was showing all files as not locked. This resolved it. – Glia

This worked for me. The above methods for "Clean Up" did not. I didn't have anything in my Work_Queue table. – Fluorescent

when I did delete from wc_lock; command in sqlite3, i got an error that the database was locked. :( ended up just redoing my checkout. ugh.. – Leach

Answer 6

A colleague at work constantly sees this message, and for him it's because he deleted a directory under SVN version control without deleting it from SVN, and then created a new directory in its place not under version control, with the same name.

If this is your problem...:

There are different ways to fix it, depending on how/why the directory was replaced.

Either way, you will likely need to:

A) Rename the existing directory to a temporary name

B) Do an SVN revert to recover the directory deleted from the file system, but not from SVN

From there, you would either

A) Copy the relevant files into the directory that was deleted

B) If you had a significant change of contents in the directory, do an SVN delete on the original, commit, and rename your new directory back to the desired name, followed by an SVN add to get that one under version control.

Whalen

Your second-step B) seems a very bad idea to me, as it would break the revision history for items of the original directory that are kept in the new version. – Suttle

The very bad things happened when the person deleted a versioned directory from the file system but not from SVN. The answer above might not be a perfect recovery, but it is a recovery. – Oink

Answer 7

For me none of the above solutions worked. I found a solution by breaking locks. When I performed svn cleanup, I selected "Break Locks" along with "Clean up working copy status".

Anesthesiologist

For me breaking lock from Tortoise SVN repo browser worked. Breaking lock on checked out folder did nothing. – Oneida

Answer 8

This one worked for me.

1. Go to the root folder,
2. Right click and cleanup
3. Check all available options
4. Press ok

After clean up it will allow you to update to the latest version.

Rubberize

This works for me too. You need check all available options (6 entries in my version) to proceed Clean Up; it gets fail if you just check [Clean up working copy status] and [Include externals] options. – Sundae

This totally worked for me... just by right-click on project > Team > Cleanup. Haven't had to remove any row from the SQL in .svn nor anything else. Just this did the job. Thanks! – Formulary

This worked for me as well in version 1.7.4 of TortoiseSVN. I went with the default check boxes that were presented. – Mailbox

Helped me today, but I didn't needed to check all available options. The last three that revert my changes I did not check, and it worked anyway. See also https://mcmap.net/q/64220/-working-copy-xxx-locked-and-cleanup-failed-in-svn – Boyt

This is highly dangerous, because some of those checkboxes would destroy local work that hasn't ever been successfully transferred to the repo. – Kataway

This worked for me. I just checked Clean up working copy status and Breaks locks and Include externals – Caparison

Did not work for me :-( I checked all options in the SVN cleanup dialog, removed all ignored files and all changes from my working copy, but I am still unable to update. – Lindie

Answer 9

For me, it was actually Tortoise's fault, sort of. Tortoise just complained "cannot clean up, run clean up", but when I ran the command line (svn cleanup), it clearly told me that it couldn't delete some files that were in use, the solution to which was obvious. Once I closed Visual Studio (which was keeping the files open), then the cleanup worked fine.

Other programs can also keep files open in the repo causing this issue. Excel holding an xls open was a culprit in another instance so it may be wise to close all programs that may be using anything in the repo or even rebooting to force programs to close out and then trying cleanup again.

Surrealism

Answer 10

I had this problem because external folders do not want to be linked into an existing folder. If you add an svn:externals property line where the destination is an existing (versioned or non-versioned) folder, you will get the SVN Woring Copy locked error. Here a cleanup will also tell you that everthing is all right but still updating won't work.

Solution: Delete the troubling folder from the repository and make an update in the root folder where the svn:externals property is set. This will create the folder and all will be fine again.

This problem arose for me because svn:externals for files requires the destination folder to be version controlled. After I noticed that this doesn't work across different repositories, I swaped from external files to external folder and got into this mess.

Impenetrable

Answer 11

The easiest way to do this is show hidden folders and then open the .SVN folder. You should see a zero KB file named "lock" deleting this will fix the problem

Fellmonger

Answer 12

I came across the exact same issue using SVN 1.7 and none of the fixes mentioned above worked.

Foremost, make sure you backup all your edited content.

After spending a couple of hours (didn't redownload everything as my branch is over 6gb in size), I found that there is a db file called "wc" in the .svn folder of your branch.

Open up the db file using any db manager (i used firefox's sqlite manager plugin) and navigate to WC_LOCK table. This table will have the entries for the acquired locks. Delete the records from the table and you're done :)

Killian

even though it was pretty much a duplicate of the previous answer, I gave you a vote because you mentioned the firefox SQLite manager plugin. – Reimpression

Answer 13

I did it by just creating a new folder, checking out the project, copying the updated files to the new folder.

It was fixed with a fresh checkout.

Tarry

I did the same. (I put the root cause down to AnkhSVN messing with my working copy. AnkhSVN is now uninstalled). – Mog

Answer 14

If you're on a Windows machine, View the repository through a browser and you may well see two files with the same filename but using different cases. Subversion is case sensitive and Windows isn't so you can get a lock when Windows thinks it's pulling down the same file and Subversion doesn't. Delete the duplicate file names on the repository and try again.

Crowson

Answer 15

When i have this problem, i find running the cleanup command directly on the problem path generally seems to work. Then I'll run cleanup from the working root again, and it'll complain about some other directory. and i just repeat until it stops complaining.

Gwenngwenneth

I couldn't find a lock file as with previous answers, but this worked for me :) – Ernest

Answer 16

I often get such an issue. My pattern that causes cleanup problems.

1. I open image file in viewer.
2. I delete image file/folder.
3. I am trying to commit/update

Closing image viewer where deleted file is opened solves the problem. Maybe other software can block cleanup the same way.

In general. I believe restarting computer may help in such cases.

Vitality

Answer 17

In Versions under Mac OS: Action -> Cleanup working copy locks at...

Richers

Answer 18

just delete the .svn folders, then run a cleanup on the parent directory. Works perfectly!!

Kalliekallista

In SVN 1.7, this won't work because there is only one .svn folder, at the top. If deleted, the attachment to the repository is removed. – Errancy

Answer 19

Are you using TortoiseSVN and just upgraded? I've had that problem before when moving from 1.4 to 1.5 and not rebooting. (Try a reboot).

The reason you need to reboot is because the cache file gets all funky.

Otherwise, to just move on, export that working copy into a new folder (don't copy the .svn hidden folders), re-checkout the project, and move all your code back, then proceed with your commit.

Glimmering

This happened to me too, that is I just needed to reboot – Schizothymia

Answer 20

For me, the problem was with completely full disk drive (linux inodes in my case), when i deleted some folders it started working again.

The error was the following (on any svn action):

$ svn cleanup
svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
svn: E155004: Working copy locked; try running 'svn cleanup' on the root of the working copy ('/my/directory') instead.
svn: E155004: Working copy '/my/directory' locked
svn: E200030: sqlite[S14]: unable to open database file
svn: E200030: Additional errors:
svn: E200030: sqlite[S14]: unable to open database file

Waterage

Answer 21

To do the clean up

1. Delete the .svn folder.

2. Do the svncheckout in the root folder.

3. Try performing the clean up operation.

This got my issue resolved.

Massie

Answer 22

Steps :

1. Close all editing files from svn folder

2. Close eclipse or any editor which are using folder or file from svn directory.

3. Right click on svn check out folder and click on release lock.

4. Right click on svn check out folder and click on clean.

5. Your SVN is ready for SVN commit and update operation.

Cheers :)

Inlaw

Answer 23

In solution explorer, right click on the project, in the opening sub-menu click on subversion and select clean-up. It will solve the problem, as it did for me. Hope it will work.

Sorn

Answer 24

I did the following to fix my issue:

1. Renamed the offending folder by placing an "_" in front of the folder name.
2. Did a "Clean Up" of the parent folder.
3. Renamed the offending folder back to it original name.
4. Did a commit.

Glabrate

Answer 25

I had this problem where the "clean up" worked, but the "update" would continue to fail. The solution that worked was to delete the folder in question via Windows Explorer, not TortoiseSVN's delete (which marks the deletion as something to commit to the repository, and then I did a "checkout" to essentially "update" the folder from the respository.

More info on the difference between an O/S delete and an SVN delete here: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-rename.html

Notably:

When you TortoiseSVN → Delete a file, it is removed from your working copy immediately as well as being marked for deletion in the repository on next commit.

And:

If a file is deleted via the explorer instead of using the TortoiseSVN context menu, the commit dialog shows those files and lets you remove them from version control too before the commit. However, if you update your working copy, Subversion will spot the missing file and replace it with the latest version from the repository.

Jemy

Answer 26

In-place unversioning of the files, and a fresh checkout into the same location, has solved this problem for me.

In TortoiseSVN, to do an in-place unversioning, right-drag the root folder of the working copy from the file list onto itself in the directory tree, and choose "SVN Export versioned items here" from the pop-up menu. TortoiseSVN notices that the destination is the same as the source, and suggests unversioning the working copy.

After unversioning, do a fresh checkout into the same folder (which now contains an unversioned copy of all the files you had). TortoiseSVN will warn you that you are checking out into an existing folder, but you can go ahead.

After this, cleanups, updates and other operations worked without a hitch. Since both of the above steps preserve local modifications, there should not be any loss of information (but backing the working copy up before this may nevertheless be a good idea).

One warning: If the working copy contains mixed versions or uncommitted property changes, that information WILL be lost. For me, this is not a common occurrence, and given the choice of a corrupt working copy or losing uncommitted property changes, I tend to opt for the latter.

Irons

Answer 27

If you're on Linux, try this:

find "/the/path/to/your/directory" -name .svn -type d | xargs chmod 0777 -R

Then run the cleanup command on that directory, then try to update.

Rawdan

Answer 28

Do not delete your solution!

in the .svn folder you have a file called lock it is 0 bytes long

You can delete all these files from all the .svn folders in your solution and it will work

It worked in my case

Smetana

This is the simplest solution! Worked for me – Scorper

Yes, unfortunately it doesn't work for the latest version of SVN. For the latest version you do have to delete it because there is no longer a lock file. there seem to no longer be any files there is a whole other folder structure. If any one knows if there is anything that can still be modified in a manner similar to the one above please share it with us. – Smetana

Answer 29

the following should do:

svn status | grep ". L" | sed 's/.* (.*)$/\1/' | awk '{print length($1),$1}' | sort -nr | awk '{print "pushd " $2 "; svn cleanup ; popd"}' | sh

Garica

Answer 30

Start Search....Lock...Select all files listed and delete..fixed

Quoth

Answer 31

I had this under TortoiseSVN and the error was related to a new directory I'd created under a new project. I had just created this project, so there was no way this directory had existed before. I looked in the repository browser and the new folder was indeed already in the repository, but TortoiseSVN didn't show it as committed.

In order to get around it, since I'd just created the folder anyway, I deleted it in the repository, and then did a commit. It worked fine.

Since I did this outside of Visual Studio, I then had to restart Visual Studio for it to figure everything out again.

Antimonic

Answer 32

Had the same problem because I exported a folder under a version-controlled folder. Had to delete the folder from TortoiseSVN, then delete the folder from the filesystem (TortoiseSVN does not like unversioned subfolders ... why not???)

Sori

I should add that I exported a folder TO THE SAME FOLDER .. this is how you unversion prev. versioned folders. – Cottier

Answer 33

SVN normally updates its internal structure (.svn/prop-base) of the files in a folder before the actual files is fetched from repository. Once the files are fetched this will be cleared up. Frequently the error is thrown because the "update" failed or prematurely cancelled during the update progress.

1. Check any files are listed under .svn/prop-base directory
2. Remove any files which are not under the folder
3. Cleanup
4. Update

Now the update should work.

Ipoh

Answer 34

just execute the cleanup option available in tortoise client

if it throws error check break write locks available in the cleanup option

Hadlock

Answer 35

As exactly this answer is not listed here: my solution was to close my IDE (in this case Netbeans). Seems like the IDE had locked the file.

Basanite

Answer 36

The clean up did not work for me no matter how many ways I tried. Instead from Visual Studio I committed each folder individually. Then I committed the top folder and was successful.

Osmosis

Answer 37

While doing svn update using tortoise svn, the process got interrupted and stopped complaining the file is in use. Next it asked me to use CleanUp command on the folder. I tried to run CleanUp command but it failed to do so. Then I found a command shell which was using the folder files. So, I closed the command shell and checked if any editor is using the files related to it. We need to close them as well. Again, I tried CleanUp on the folder with options Break locks,revert changes,clear working copy status . The CleanUp went successfully. Then finally able to update my svn folder.

Unheard

Answer 38

First of all tried many solutions, then I just deleted the folder in which I was having trouble.

And then performed SVN Update.

That worked for me.

I would not recommend it, but nothing worked but this. :(

Correlative

Answer 39

One reason for this problem I haven't seen in the answers is that an update or checkout may have been done with other user/permissions, like for example with $sudo.

Grebe

Answer 40

Today I have experienced above issue saying

svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

And here is my solution, got working

1. Closed Xcode IDE, from where I was trying to commit changes.
2. On Mac --> Go to Terminal --> type below command

svn cleanup <Dir path of my SVN project code>

exmaple:

svn cleanup /Users/Ramdhan/SVN_Repo/ProjectName

3. Hit enter and wait for cleanup done.
4. Go To XCode IDE and Clean and Build project
5. Now I can commit my all changes and take update as well.

Hope this will help.

Interfaith

Answer 41

Clean up certainly is not enough to solve this issue sometimes.

If you use TortoiseSVN v1.7.2 or greater, right click on the Parent directory of the locked file and select TortoiseSVN -> Repo Browser from the menu. In the Repro Browser GUI right click the file that is locked and there will be an option to remove the lock.

Tatia

Answer 42

I know this is a really old thread but I maintain that:

The easiest and safest method to fix this is to delete your hidden ".svn" folder and check everything out again.

It fixes most problems when svn screws around should keep local changes (marked as "conflicted") when you check out the head revision again.

Shoeblack

Answer 43

I had the same problem. Seems it has been fixed in the latest versions. I have updated my Tortoise SVN to the latest version (1.7.11) and clean up has worked well.

You can download the latest version here: downoad tortoise svn.

Vostok

Answer 44

Updating the directory permissions (granting write access) solves the problem as well.

chmod +w <dir_name>

Sorry

Answer 45

I had a file in my root directory that was messing it up. (No lock files, svn cleanup failed, etc.) My whole checkout is > 2GB with slow network speeds, so checking everything out again wasn't a great option for me.

What worked for me:

1. Reverted & reverted change in the messed up working copy (#1).
2. Checked out another copy of the repo (#2) with --depth empty
3. Added and committed the file in the new working copy (#2).
4. Updated in the original working copy (#1).

Seemed to be back to normal for me.

Smoot

Answer 46

@Chuck's solution wasn't practical for me. In the first time I had the problem, it worked but also gave lots extra-work. In the second case, I changed loads of file while I was using my notebook outside the network. I couldn't see myselft going folder by folder after the changed files. Had hope on tortoise and worked. See how:

Environment Was:

1. Visual Studio 2008
2. Ankhsvn

Procedure:

1. First I couldn't commmit, it said that I needed to clean up
2. Second, I couldn't clean up, there was a folder out of the svn - "bin"
3. I downloaded Tortoise lastest version, tried and doesn't work due to dammed folder.
4. Renamed that folder and now I could Update the local repository with the lasted version.
5. A couple of files came in.
6. Did the commit and worked.

Edda

Answer 47

In my case, a Windows 7 machine running TortoiseSVN failed to rename a folder completely. No combination of cleanup, update, or rename operations would fix the problem. The folder was originally created with different case and Tortoise or Subversion would not change it to what was in the repository.

My solution was to:

1. Copy the folder through Windows Explorer (without Subversion control files) outside the project.
2. Delete and commit the folder through TortoiseSVN.
3. Copy the folder back with the correct (current) name through Windows Explorer.
4. Add the folder back into the repository through TortoiseSVN.

I performed cleanups after each step. Dreadful solution, but it worked for me.

Bonus

Answer 48

These types of problems can be avoided in the first place by using svn copy and svn move etc commands when making changes to your project structure. Remember svn only checks for changes inside files already added to subversion, not changes to the physical directory structure. Please see http://svnbook.red-bean.com/en/1.7/svn.tour.cycle.html

Further, upon committing changes svn first stores a "summary" of changes in a todo list. Upon performing the svn operations in this todo list it locks the file to prevent other changes while these svn actions are performed. If the svn action is interrupted midway, say by a crash, the file will remain locked until svn could complete the actions in the todo list. This can be "reactivated" by using the svn cleanup command. Please see http://svnbook.red-bean.com/en/1.7/svn.tour.cleanup.html

Weissberg

Answer 49

Spotlight is its usual rubbish self at finding the lock files recursively.

EasyFind on Mac App Store works

http://itunes.apple.com/gb/app/easyfind/id411673888?mt=12

search for 'lock'

Select all / Delete

Conglobate

Answer 50

I am sure It working fine for you

Goto top level SVN folder.

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

This will surely solve your problem.

Celina