On Fri, 12 Jan 2007, Nathan Kidd wrote:
> Malcolm Rowe wrote:
> >On Fri, Jan 12, 2007 at 10:30:30AM -0500, 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? 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
> >>
> >
> >I'd rather we try to make it impossible to have orphaned locks in the
> >first place :-) Is that a hard problem?
>
> Any repo of mainly non-mergable data that uses a 'svn:needs-lock on all
> files' model is extremely likely to have these orphaned locks. There
> needs to be a way to clean old/existing repositories. Of course
> remove-zombie-locks.py can do this now, it's a question of whether this
> is such a core problem that it should be built into svnadmin or not.
Hmm, I've been wondering the same thing as Malcolm. Why don't
operations which could cause orphaned locks -- 'delete', 'move' (?),
etc. -- check whether the target and child paths have any of the lock
properties set on them, and take the appropriate action?
- application/pgp-signature attachment: stored
Received on Mon Jan 15 21:07:55 2007