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. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
