C. Michael Pilato wrote:
> dev-folk, this is in reference to the problem in issue #2507.
>
> Nathan Kidd wrote:
>> I'm not sure I'll have time, but would a patch for svnadmin adding the
>> "clean whole repository" functionality likely be accepted?
>
> What are you thinking in terms of an implementation?
I hadn't thought even as far as you suggest below, but I do think this
needs to be a very simple, one-line operation if it is worth
implementing at all. It has to be much simpler than what can already be
done now:
for lockpath in 'svnadmin lslocks myrepo'; do
svn ls myrepo/mypath || svnadmin rmlocks myrepo lockpath
done
> Having invested
> about three minutes on it, here's what strikes me as do-able at the moment.
>
> Add the following flags to 'svnadmin rmlocks':
>
> --recursive (-R): descend recursively
> --only-orphaned: only operate on locks for paths not in HEAD
If -R eliminates the need for the 2nd LOCKED_PATH argument and operates
on *every* lock (as I assume it must) then if not used in conjunction
with --only-orphaned I think it not only be very dangerous, but also
serve little purpose. I'd be more inclined toward 'svnadmin rmlocks
--remove-all-orphans'
If people really want to remove all the live locks in their repo they
can always loop over lslocks output.
> --wait: wait instead of exit if the repository is in
> use by another process
>
> If we have a reason to do so later, we could also add --only-orphaned
> and --wait to 'svnadmin lslocks'.
Is this needed? In my real-world usage I never cared *what* the
orphaned locks were, I just wanted to get rid of them.
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 12 17:50:50 2007