On Sat, Dec 15, 2012 at 03:03:26AM -0800, Joe Mistachkin wrote:
>
> j. v. d. hoff wrote:
> >
> > POLS comes again to mind.
> >
>
> The Principle of Least Surprise is not static. Changing the current
> behavior
> would be a huge (and potentially unpleasant) surprise for those who are very
> actively using Fossil now.
It shouldn't be a surprise, as the migration is currently proposed,
unless all those users never upgrade Fossil SCM between now and the some-
future-time final change in functionality, thanks to the behavior
migration warnings and other indications (including, presumably, a major
version number change) that should apply along the way.
> >
> > I can tell you that I _was_ surprised (being also a user of svn and
> > hg) when I installed fossil quickly read through the help ("ah yes,
> > ci, add, pull, push, rm, mv, stat, log -- default naming scheme for
> > default tasks"),
>
> Of course, there are much bigger differences between Fossil and those other
> systems than the semantics of "mv" and "rm".
. . . most of which are not *bad* differences like this one.
> >
> > and I do not buy the "it'll be really dangerous for so many people"
> > prophecy.
>
> Obviously, I do buy it. Breaking compatibility is generally bad. It's
> even worse when other _software_ (i.e. not humans) may depend on the
> current semantics. The surface area of Fossil is the set of command
> line options it exposes, since it's a command line tool. In this case,
> it would not be unlike changing the default behavior of the Unix "rm"
> command to implicitly include the "-f" option.
Should all software never ever break any backward compatibility ever,
just because something may be automated somewhere by someone who will
never pay attention to warnings given by the software itself or will skip
many intermediate versions before upgrading to a new, post-change
version? Should we always plan changes only for the sake of the most
irresponsible users?
What are your criteria for allowing something to change? What if all rm
did was give you a warning saying "You need to issue the command wakka_
wakka_dingbat_eliminate_this_file_from_the_repository because the rm
command is only a documentation helper!"? Would you say we should never
change the behavior of rm and leave everyone stuck with wakka_wakka_
dingbat_eliminate_this_file_from_the_repository forever after to serve
the demands of backward compatibility?
If your answer is "No, of course not! That's just silly!" then we've
reached a point of agreement where we have established that sometimes
breaking backward compatibility is a good idea. All that remains at that
point is negotiating the specific cutoff point between "good idea" and
"bad idea".
If your answer is "Yes!" on the other hand, I think you and I have
absolutely zero common ground for discussion of the matter at all,
because wakka_wakka_dingbat_eliminate_this_file_from_the_repository with
the described `rm` behavior referring to it is intentionally meant to be
regarded as silly beyond reason. If to you it's perfectly reasonable to
leave it as-is, we aren't even speaking the same language.
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
