RE: recursive find locks/unlock in repository
From: Rupa Bholanath Lahiri <RupaB_Lahiri_at_infosys.com>
Date: Fri, 28 Aug 2009 10:12:12 +0530
Thank you. I will post again if I have any further queries on this.
Regards,
From: Ullrich.Jans_at_elektrobit.com [mailto:Ullrich.Jans_at_elektrobit.com]
Hi everyone,
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.
Cheers, Ulli
________________________________
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)
I don't know if these options have been considered before, but I searched the web for awhile without finding anything very relevant.
--Todd
----------------------------------------------------------------
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.
Thank you.
------------------------------------------------------
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
|
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.