Re: [Monotone-devel] [patch]move attributes on rename

[Nathaniel Smith]

On Mon, May 02, 2005 at 06:31:59PM +0200, Henrik Holmboe wrote:
> Nathaniel Smith <address@hidden> writes:
> [...]
> >It's true this a little confusing, though.  Easiest solution: add a
> >"--do-it" command-specific-option to drop/rename, which tells them to
> >actually delete or rename the file in question.  Alternate solution:
> >make the default to do it, and add a "--not-really"
> >command-specific-option. For this to be acceptable, though, I think on
> >"drop" we'd have to cache the deleted file somewhere, for disaster
> >recovery.
> 
> I would suggest that Monotone shouldnt contain a built-in "Traschcan",
> for the very same reason rm doesnt.

Glib answer: rm is a data removal tool.  monotone is a data
preservation tool.  Somewhat different focuses :-).

More serious answer: when a user types "rm" they want a file removed.
when a user types "drop" they either want a file removed, or they just
want to stop tracking it in their VCS.  How do we know?  And with both
options available, it's easy for a user to get confused and pick the
wrong one.  Also, unlike rm, we know that this is rather valuable data
(in the grand scheme of things), if the user ever saw fit to put it
under VCS, so it's less unreasonable to do...

> 'drop' should IMHO remove the file and 'move' should move the file and
> if the user wishes not to then it should be configurable in monotonerc
> that you want to be questioned first (much like the equivalent alias
> rm="rm -i" does for the shell).

rm -i is a user-interface disaster.  It's _only_ effect is to train
everyone to type "rm -f" without thinking about it.

Anyway, the question isn't whether monotone should check for
confirmation first, it's whether monotone should
remove the file from VC _and_ disk, or just remove the file from VC.

-- Nathaniel

-- 
In mathematics, it's not enough to read the words
you have to hear the music