remove vs rm vs forget

[Jari Aalto+mail.perl]

* Mon 2006-06-05 Michael Ellerman <michael AT ellerman.id.au>
* Message-Id: dc1166600606041645p5bb73456tdaba2e3757ab757e AT mail.gmail.com
>
> I'd suggest:
> - "bzr rm" is deprecated.
> - "bzr remove" is an alias for  "bzr unversion" and does the opposite
> of "bzr add".
> - when users want to remove a file they just "rm" it.
> - when this happens the file becomes "missing" in bzr terms
> - you can't commit with "missing" files, you have to either recreate
> the file, or "bzr unversion" it.
> - there should be an easy way to say "unversion all the currently
> missing files".
>
> This has the, IMHO desirable, properties that:
> - bzr never deletes user data.
> - users can use standard tools to remove files, eg. "rm" or via Nautilus.
> - but, because removal is a potentially dangerous operation, there's
> still a confirmation step required.
> - it's harder to accidentally unversion a file.

It was suggested that

    bzr rm --delete

I understand that people are facinated with new fancy word like
"unadd" or "unversion" to better describe actions that happen, but
I would put more weight on the existing convention that people are
already user to.

The command

    rm

Has established history since day one. The meanin is clear even in context
of VCS:
    
    "remove file from repository (or whatever it's properly called)"

The SVN follows this convention with good success. People are familiar
with it. An extra option to physically delete the file from local disk
is in in par with the idea of:

    "Do something more"

And the command
    
    bzr rm [--delete]

is simply

- Elegant
- Self explanatory
- Need not much explanation to existing users (supposing Unix here)

The "remove" and "rm" can be synonyms of course, so that they 
serve both command line users and backend delevelopers.

Jari