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