How can I release locks in Subversion recursively?

Question

I am having a problem with version control in Subversion. I checked out a working copy from respository and got locks on all of its files. Then, without releasing the locks I have deleted the folder from disk.

• I can't delete the folder from repository, since its got a lock
• If the I and try to release the locks recursively, it says there are no locks to be released.
• In Browse Repository view, I can only break the locks on particular, not folders recursively.

How can I break the locks residing in repository? I am using TortoiseSVN on Windows. Is there a command to break locks recursively for a folder?

Scalar

Have you tried to do a cleanup on your working copy ? – Schuller

Yes I had tried that. I had deleted my working copy with locks intact. Now if I checkout a working copy, it won't have any locks. – Scalar

You working copy does not have locks anymore ...do the files/folder have locks in the repository ? – Schuller

yes. Its goes like - I checked out a working copy, then got locks on all the files. Then without releasing the locks I deleted the working copy. That caused the locks to be preserved in repository. Anyway have solved this now. Thanks. – Scalar

Answer 1

Ok I got it. Here's what worked for me.

• Check out a working copy
• Then go in Windows explorer menu, TortoiseSVN -> Check for modifications...
• Click on Check repository button
• Select All the files, right click and select the break lock option
• Delete the working copy and the one in repository. Voila! :)

Scalar

I think this will only work if your the user that locked the files. If your stealing the lock then I think the command line is your only option. – Shakedown

This worked for me -- I was able to break someone else's lock. – Noonday

If another person holds the lock you can use the Get Lock option and mark the "Steal lock" checkbox (I had a similar problem where SVN told me that there is a lock when I tried to commit some changes but did not show me who / why in the usual tables) – Ednaedny

Answer 2

Doing an SVN cleanup will release the lock as well:

$ svn cleanup

Solipsism

This works particularly well when Tortoise (or whatever client) isn't making sense. I tried to commit, and Tortoise crashed. On subsequent attempts, Tortoise told me that some of the files were locked. Checking the repo, none of the files made it up, so it was a local thing, but none of the above answers worked for my situation. This one did (By right clicking the folder in Explorer -> TortoiseSVN -> Clean Up... And ran it with the option "Clean up working copy status". After that everything worked great. – Must

Working great when Xcode locks your files because it was not able to commit completely (for whatever reason) – Winny

Didn't work for me. I was trying to delete a folder which had locks from someone else, and even after I checked out the problematic folder and ran svn cleanup on it then svn delete on it, I still couldn't commit because the locks were still on the server. – Zitvaa

Does not work on locks created by svn lock. It cleans only implicit locks created by a broken commit etc. – Tessler

Answer 3

From the advance locking section

$ svn status -u
M              23   bar.c
M    O         32   raisin.jpg
       *       72   foo.h
Status against revision:     105
$ svn unlock raisin.jpg
svn: 'raisin.jpg' is not locked in this working copy

That simply means the file is not locked in your current working directory , but if it is still locked at the repository level, you can force the unlock ("breaking the lock")

$ svn unlock http://svn.example.com/repos/project/raisin.jpg
svn: Unlock request failed: 403 Forbidden (http://svn.example.com)
$ svn unlock --force http://svn.example.com/repos/project/raisin.jpg
'raisin.jpg' unlocked.

(which is what you did through the TortoiseSVN GUI)

Coyotillo

I also did what you told in the repository, but if I had to do it one file each, it would have taken me ages. Since my limited knowledge with cli didn't allow me to find a recursive command, that is why it took me a little more time. :) – Scalar

@ShiVik: true there is no recursive option, but you can find some way to script it: old.nabble.com/… svnadmin lslocks <path_to_repo> |grep -B2 Owner |grep Path |sed "s/Path: \///" | xargs svn unlock --force for example. But the TortoiseSVN GUI is a good solution too. – Coyotillo

Funny thing. Just finding this. If they are using TortoiseSVN they WON'T have grep, sed, and xargs. Those are Linux programs that aren't part of Windows unless you go through multiple steps to try to get them. – Lymphatic

@RichardRobertson No "multiple steps" necessary, only one: https://mcmap.net/q/338997/-git-grep-and-xargs-in-windows-batch-file – Coyotillo

Actually that remains several steps. First you have to install a Git for Windows release. That's usually multiple steps in its own right. First they have to select a version. Then do a download of that version. Then (possibly) do file property change to unblock that installer so there are no issues with Windows security. Then run the installer and go through x number of prompts. Now, why would a person being installing Git if they are using Subversion? Why would they be expecting to do that in the first place? – Lymphatic

@RichardRobertson No setup necessary: just an auto-extract archive. Decompress it wherever you want, add the right folders to your PATH, and you are done. You are not "expected" to do anything you don't want. I am just pointing out I have been using 200+ Linux command right from my CMD for years, without any setup/msi. Note that I forgot this was about SVN. I haven't used (or thought of) that tool in years. – Coyotillo

@Coyotillo - Uh, that's still a setup process. Count the steps you just stated. ALL the steps. Is it more than three? Let's see. Locate archive(!), download archive, find a place that seems reasonable to decompress it to, decompress to that location, go through the several steps to add the folders to the PATH variable... then you are able to use the Linux commands from a CLI (I use PowerShell myself, not CMD). "Setup" doesn't mean just to run a setup program, but it describes a process to enable certain functionality that wasn't already present. – Lymphatic

Answer 4

If somebody else has locked the files remotely, I found that using TortoiseSVN 1.7.11 to do the following successfully unlocked them in my working copy. (similar to vikkun's answer)

• Right click working copy > Check for modifications
• Click Check repository button
• Select files you wish to unlock
• Right click > Get lock
• Check "Steal the lock" checkbox
• After lock is stolen, select again
• Right click > Release lock

Files in working copy should now be unlocked.

Kirkpatrick

Answer 5

Unless you have admin access to the svn machine and can use the 'svnadmin' tool, your best option seems to be this:

1. Checkout the problematic directory using svn checkout --ignore-externals *your_repo*
2. Use svn status --show-updates on the checked out repository to find out which files are potentially locked (if someone finds the documentation on the meaning of the status codes please comment).
3. Use svn unlock --force *some_file* on the files found at 2.

I've used the following one-liner to automate 2. and 3.:

svn status -u | head -n -1 | awk '{ print $3 }' | xargs svn unlock --force

Zitvaa

Answer 6

If you have access to the svnadmin tool in the repo server, you can use this alternative to remove all locks (based on the script posted by VonC)

svnadmin lslocks <path_to_repo> |grep -B2 Owner |grep Path |sed "s/Path: \///" | xargs svnadmin rmlocks <path_to_repo>

Malaya

This command does not work for files with whitespaces. You need "xargs -d '\n'" to make sure xargs only treats new lines as delimiter. – Medicate

This is server side, the question was about a working copy (client side). – Fourier

Answer 7

The repository administrator can remove the locks (recursively), operating on hundreds of files inside a problematic directory -- but only by scripting since there is not a --recursive option to svnadmin rmlocks.

$repopath=/var/svn/repos/myproject/;
$problemdirectory=trunk/bikeshed/
IFS=$'\n'; for f in $(sudo svnadmin lslocks $repopath $problemdirectory \
| grep 'Path: ' \
| sed "s/Path: \///") ; \
do sudo svnadmin rmlocks $repopath "$f" ; done

This solution works with filenames that have spaces in them.

Fanelli

Answer 8

For me deleting the lock file inside .svn did not work since I got bad checksum msg after trying to update the file.

I got the following msg after executing svn cleanup inside the directory:

svn: In directory '' svn: Can't copy '.svn/tmp/text-base/file_name.svn-base' to 'filename.3.tmp': No such file or directory

So I copied my file to .svn/tmp/text-base and changed the name to file_name.svn-base. Then cleanup and update worked fine.

Quadruped

Answer 9

When I tried to run the script from above as originally provided, I was getting an error when it tried to set the variables: ./scriptname: line1: =/svn/repo/path/: No such file or directory ./scriptname: line2: =directory/: No such file or directory

I removed the '$' from the first two lines and this worked perfectly after that.

repopath=/var/svn/repos/myproject/;
problemdirectory=trunk/bikeshed/
IFS=$'\n'; for f in $(sudo svnadmin lslocks $repopath $problemdirectory \
| grep 'Path: ' \
| sed "s/Path: \///") ; \
do sudo svnadmin rmlocks $repopath "$f" ; done

Ehrenburg

Answer 10

You can use chmod with 777 permission

$ chmod -R 777 <directory-name>

Let me explain this command: chmod command is used to change the access permissions of files and folders.

File permissions are defined by three numbers. Each number can be anything from 0-7. The numbers represent different permissions, and the order of the numbers represents who the permissions apply to. Specifically, the first number represents permissions for the file owner, the second for the group that owns the file, and the third for everyone else.

Here's what each number means:

• 0: No permissions
• 1: Execute only
• 2: Write only
• 3: Write and execute (1+2)
• 4: Read only
• 5: Read and execute (4+1)
• 6: Read and write (4+2)
• 7: Read, write, and execute (4+2+1)

So 777 means that everyone (file owner, group members, other users) can read, write, and execute the files.

And -R flag means recursively give all the subfolders this permission.

Guerin