On Fri, 30 Nov 2012 15:30:13 +0100, Chad Perrin <[email protected]> wrote:
On Tue, Nov 20, 2012 at 06:10:00PM +0100, j. van den hoff wrote:
On Tue, 20 Nov 2012 16:48:00 +0100, James Turner
>
>I'd suggest -f like cvs rm uses.
obviously everybody seems to have his/her own preference how to
handle this. so only a fraction of users will be happy in the end it
seems. -- I would again second the proposal
of Remigiusz Modrzejewski in this thread: after a 'grace' period
when it would behave in the way you propose (explicitly add a -f
flag to enforce deletion), finally change the default to what
_current_ VCSs (>= svn) seemingly all (?) do by default which is to
treat `svn(hg, git, bzr) rm' as meaning
"remove from repository and also remove the working copy" while
relegating different behaviour (if at all) to an option such as "bzr
rm --keep".
in my way that is the most frequently intended behaviour which
should therefore be the default.
sure a matter of taste as so many things, but at least it would
avoid surprises here for refugees from one of the other systems.
I think that makes sense, with the addition of using Matt Welland's
suggestion of scheduling the move to compatibility breaking behavior on a
2.0 release. This is the purpose of common semantic versioning, after
all: major version numbers (the "integer" portion, essentially) are for
indicating breakage in backward compatibility for system features.
I think that doggedly sticking to current default behavior for all time
is a bad idea for a number of reasons[1], but that making changes to
expected defaults before a major version number increment is also a
rather bad idea.
[1]: . . . such as potential for error when using multiple DVCSes in
parallel and discouraging people from adopting the software.
I fully support this reasoning. the last point, especially, is not to be
taken lightly. but of course behind that is the basically more important
aspect that it (i.e. `rm' doing both, removal from tracking and deleting
the checked out copy) would be a saner default, probably.
j.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
