break-lock should have a --yes, --force or --unconditional option

Bug #397315 reported by Martin Pool
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
Medium
Martin Pool

Bug Description

Sometimes, eg when debugging locking, you know you really want to break a lock without being asked. There should be an option that will do it without asking.

There is some risk people will harm themselves using this if there really is still a live process.

As a workaround on unix you can say "yes|bzr break-lock blah"

See also bug 397298 for checking if the locker is still alive

Related branches

Revision history for this message
Martin Pool (mbp) wrote :

This would be part of a solution for bug 257217, stale locks generated by killing the process.

Changed in bzr:
assignee: nobody → Martin Pool (mbp)
importance: Low → Medium
status: Confirmed → In Progress
Martin Pool (mbp)
tags: added: confirmation lockdir locking ui
Revision history for this message
Martin Pool (mbp) wrote :

trunk now has a 'confirm_action' method on the ui, which gives a path to allowing users to turn all interactions off, or to turn them off when particular options are set.

I'd like to add --confirmations=yes/no/ask, ask being the default, and these can usefully be global options.

istm we should split the ui factory mechanism of talking to the user from the policy about what kind of interactions with the user the program wants to have. Perhaps we can interpose a policy decorator around the factory.

Revision history for this message
Martin Pool (mbp) wrote :

This branch has a --force option that configures the UI not to ask about lock breaking.

Vincent Ladeuil (vila)
Changed in bzr:
milestone: none → 2.3b2
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.