remove vs rm vs forget (was [MERGE] remove --new)
Michael Ellerman
michael at ellerman.id.au
Mon Jun 19 04:47:44 BST 2006
On 6/19/06, Kevin Smith <yarcs at qualitycode.com> wrote:
> On Sat, 2006-06-17 at 10:18 +1000, Martin Pool wrote:
> > I think that's reasonable; to start with we can just do rm without
> > the option and make the backup file. We can then use the same model
> > for revert of a newly-added file: move it to a backup and then you
> > haven't lost anything.
> >
>
> Would it be possible for rm to check to see if the working file matches
> what's been checked in? If it does, then deleting the file is safe
> because you can revert. If not, I would be ok with an error message
> telling me that if I *really* want to remove it, I have to say --force
> or something.
>
> It might also fail if the file is archived but not present locally,
> again requiring a --force option. Or maybe --unversion for this case,
> and --delete for the opposite case above.
>
> That way, rm could normlaly remove the file locally and from the
> archive, which would be consistent with mv. I think it's the least
> surprising action, personally.
I think that could be _more_ suprising, because sometimes the file
will be deleted and sometimes not. It might be obvious to you and me
why it gets deleted sometimes and not others, but it's likely that
some users won't get it.
It could print out "not deleting foo because it's modified locally"
though to alleviate that.
My point of view on this is we want a do-what-I-mean interface, BUT
deleting files is _really fraught with danger_, so it should be _hard_
to make bzr delete your data for you.
cheers
More information about the bazaar
mailing list