First thing: sorry for the other post - Out&**% got away from me.
Second: sorry for the top post - Out&*^k won't let me post normally on
this mail - weird, it wants to extend the quote...
Anyway: try this:
svnadmin lslocks <path_to_repo> |grep -B2 Owner |grep Path |sed "s/Path:
\///" |xargs svnadmin rmlocks <path_to_repo>
I suspect this grep for the owner can be left out as well, but I wrote
this some time ago and there were only the locks of a certain user to be
deleted. (In the original, there was another grep -B2 <username> to only
unlock the stuff that user had locked...
Of course, this is supposed to be done on the server.
From: Todd C. Gleason [mailto:tgleason_at_impac.com]
Sent: Monday, August 17, 2009 7:11 PM
Subject: recursive find locks/unlock in repository
We recently had a need to recursively break all the locks in an
Svn repository. Unfortunately, I could not find a straightforward way
to do an unlock or find type of operation.
The best I was able to figure out was to do "svn checkout [URL]
--depth empty" above the level of trunk/branches/tags, and then
svn stat . --depth infinity --show-updates
The results of this were ultimately piped through grep, looking
for "O" in the sixth column. A lot of data was sent down from the
server for this to happen-something like 130MB, because for all the
tags, branches, and trunk, svn stat showed every file as existing on the
repo but not in the empty WC (and there are tens of thousands of files
in the first place).
This strategy doesn't scale very well, so I'm hoping that either
I missed some magic or that a future release will include a way make
this happen more readily. My suggestion would be for a few things:
1. svn stat should be able to filter for locks (maybe
something like --show-locks)
2. svn stat should be able to run against a URL, not just a
3. svn unlock should be able to take a --recursive
parameter when run on a folder. (Right now I believe it just errors out
when you try this.)
I don't know if these options have been considered before, but I
searched the web for awhile without finding anything very relevant.
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Received on 2009-08-21 10:36:36 CEST