On Fri, Dec 14, 2012 at 10:32 AM, Chad Perrin <[email protected]> wrote:
> On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote: > > > > This is the classical divide between pragmatists (I want to get my job > with > > with minimal pain so I can go home a play ball with my son) versus the > > idealists (source code management means doing x, y and z and no more and > no > > less and I'm sorry that it will take you twice as long to do your job > right > > *grin*). > > > > Fossil is caught between the messy world of the pragmatists and the nice > > tidy world of the idealists. There is no one right way to do it. One > group > > or the other will be disappointed. > > I don't think that's all there is to it. It isn't really fair to those > who prefer automation of the full set of rm tasks to suggest they > necessarily lack a sense of the idea, or to those who oppose that > automation to suggest they lack a sense of pragmatism. I think that the > two sides of this discussion are more sophisticated and complex than > that, with several different types of argument being possible and > presented on each side. The major argument types I have seen so far are: > > for rm automation | against rm automation > ----------------------------------|---------------------------------- > idealist (Unix way) | idealists (airbags way) > pragamtists (POLS way) | pragmatists (backward compat) > trolls (haven't noticed any) | trolls (NIH and "you're dumb") > > If you know of any trollish argument forms on the pro-automation side, > please feel free to point them out. I may be suffering some confirmation > bias in this case. Anyway, my explanations of the various arguments, as > I have noticed them, follow. > > * Unix way idealists: When you tell it to do something, it damned well > does it. > > * airbags way idealists: When you tell it to do something that might be > accidentally applied in an unintentionally destructive manner by an > incautious user, it should second-guess your intentions and try to > convince you to do things differently, on the assumption that is not > what you wanted. > > * POLS pragmatists: When you issue a command that seems like it should > perform a given task, you expect it to perform the whole task, and not > only part of it. Tool design should account for that. > > * backward compat pragmatists: This is how it has been done so far, > establishing a set of expectations particular to long-time users and > the automation scripts they have written that rely on the behavior in > question. We should not change the tool's behavior to violate those > ingrained expectations because there may be backward incompatibility > problems. > > * NIH trolls: You're trying to turn Fossil into Git! Stop it! > > * "you're dumb" trolls: Obviously you are all too stupid to understand > the benefits of keeping things the way they are. You are wrong because > you are stupid; you are stupid because you disagree with me. > > If we could eliminate those "troll" category participants in the > discussion, I think we would get a lot further in sorting this out. > Nice analysis Chad! My sincere apologies to anyone insulted by my overly simplistic and arguably unfair comment :) I still want one of these two: Preferred behavior: remove file silently from disk iff the file is controlled and unchanged or if forced with -f. Issue a warning if the file was not removed. Also works for me: don't remove files unless forced with -f. With force all removals on disk happen without any notice. -- 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 >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
