On 12/13/12 05:01, Themba Fletcher wrote: >>> What's next? Replacing SQLite with individual files? >> >> Absolutely not, and statements like this do more harm than good because they >> willfully disregard the point of what is being expressed. The point is not >> to be alarmist and extreme, as statements like the above are. The point is >> to establish that there is a certain behavior that is expected, and Fossil >> does not exemplify that. > > Sure. But without fossil's deviation from the norm what possible > reason would I have to choose it over mercurial or git?
I recall a discussion about implementing a "? :"-operator in a non-C language a few years back. Some simply suggested "why not use '? :'?", and some developers said "That's C -- we're not C". So someone posted a convoluted syntax which it seemed like almost everyone hated, but the "hard core" users said it was ok, "because it wasn't C". I don't want decisions about fossil to be made on that basis. "If we change this behavior to the better, we'll become more like others, so we can't have it.". Being different isn't of any value if the difference doesn't imply improvement (in the case of mv/rm I think fossil's behavior is inferior to others). Extrapolating "make rm and mv behave main-stream" to "we'll become just like mercurial or git" seems to be a little of a stretch to me. I have zero objections to becoming "main stream" with regards to certain features if it means becoming better. Some of the reasons I use fossil are: I trust SQLite, SSL, I like that it uses HTTP as its clone-protocol, the REMOTE_USER feature, I like the web-ui (with all its features), I like the command line ui (mostly), I like the strict DAG property of the repository, the built in wiki, ticket system, user administration, etc. The fact that I have to perform two operations for something which should only require one is _not_ a reason for me to chose fossil over any other system. But more to the point: Even if I saw any value in the separation, such a feature would still not be a reason for me to chose fossil over any other system. It would have exactly zero bearing. I don't see changing the current rm/mv behavior as removing a selling point of fossil (and frankly speaking, I'm quite surprised to see that it's being treated as such). I see it more limiting the number of replies to the question "Ok, so you've brought up the pros with fossil. Could mention some of the cons?". I don't think there are many annoyances with fossil, so the mv/rm behavior is a relatively minor issue in the grand scheme of things, but still -- could we make it do all of the work, not just half of it, I would be pleased and have one less "con" in my list. -- Kind regards, Jan Danielsson _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
