design note: allow recovery rather than prevent-mistakes

Martin Pool mbp at sourcefrog.net
Tue Jul 21 01:09:34 BST 2009


2009/7/20 Jonathan Lange <jml at mumak.net>:
> On Mon, Jul 20, 2009 at 6:48 PM, Robert
> Collins<robertc at robertcollins.net> wrote:
>> An early choice made in a lot of bzr was to allow people to recover
>> rather than strictly prevent mistakes. Not all of bzr does this, and I
>> don't think all of it should: not all things are easy to recover from,
>> or able to be [cheaply] made easy to recover from.
>>
>> I think its worth remembering though: when proposing UI changes, try to
>> bear this in mind: its might nicer as a user to be told that something
>> is unusual and how to undo your action, than to be told that you cannot
>> do the action at all. Where some users want to absolutely prevent the
>> action, having an optional --strict, like we do in commit, can be a nice
>> compromise to achieve that.

This is a good point.  I was thinking something similar after the
discussion about rm.

We could apply it in more cases - for instance, perhaps commit at
least run the equivalent of 'bzr resolve' by default.  Or perhaps to
take it even further it should *actually* commit and just warn that
you seemed to be committing conflicts - though that might be too far.

> I agree with this design principle, and wish Launchpad embraced it
> more strongly.
>
> Is there somewhere we can record this principle so it can be referred
> to in future discussions? The HACKING guide perhaps?

Yes, I think it would be good to put that in there, in a section of principles.

-- 
Martin <http://launchpad.net/~mbp/>



More information about the bazaar mailing list