Weighing in on this, finally:
It's interesting to me that everyone speculates that this *might* break
things for some hypothetical person, and *might* bite someone, but has
anyone here ever been bitten by it?
And is it not something that "fossil revert" could undo?
I don't mind avoiding the change until a 2.0 release, but I worry about
making it a setting, because I prescribe to the idea that settings add
complexity both for users and developers.
My $0.10 adjusted for inflation: keep the existing behavior until 2.0,
then just change it. There are plenty of settings already, please don't
add another, especially for something that we're all speculating might
affect someone who can't just revert for whatever reason.
On 11/30/2012 08:58 AM, j. v. d. hoff wrote:
On Fri, 30 Nov 2012 15:30:13 +0100, Chad Perrin <c...@apotheon.net>
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.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
