Le 2012-12-14 12:50, Matt Welland a écrit :
On Fri, Dec 14, 2012 at 10:32 AM, Chad Perrin <c...@apotheon.net <mailto:c...@apotheon.net>> 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.
+2
Also works for me: don't remove files unless forced with -f. With force all removals on disk happen without any notice.
+1 -- Martin G. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
