On Oct 11, 2016, at 6:38 PM, K. Fossil user <ticketpersonnal-fos...@yahoo.fr> wrote: > > 1/ I ask for a poll
If you mean your request nearly 4 months ago in the thread about how the mailing list is run, a poll isn’t going to affect anything. This project is not a democracy. Like virtually all other open source projects, it is a do-ocracy: that is, those who do the work make the rules. User voices do occasionally sway those who do the work, but ultimately the project runs the way they want it to run. > 2/ I've tried to compile Fossil it did not… I’ve rebuilt Fossil several times over the past few days. It still builds just as easily as it ever did. “It did not” is not something we can help you with. If you want help with build problems, post your OS and compiler details along with the error messages you got. > 3/ I asked about a guy's opinion when it comes to Fossil in production use : > He said no. Note that he plays with huge projects. Several very famous people claim that vaccines cause autism, despite decades and millions of dollars of research. Testimonials are not facts, and expertise is relative. > I've read that a big part of Fossil code is SQL with SQLite which is not for > big project. Big projects uses PostGreSQL, MariaDB, Percona, Oracle, IBM SQL > (DB2 and so on) … Project size is almost the very last consideration to take into mind when considering the DBMS to use. Features, cost, administration, etc. are far more important. By your logic, Git is even less suitable to large projects because it doesn’t use a DBMS at all, and “everyone” knows that large projects require a DBMS. SQLite has two major weaknesses compared to the client-server DBMSes you mention: 1. SQLite proper is not client-server, so it is a bad choice when multiple computers need to modify a single DBMS instance. This is not a problem for Fossil because we have “fossil server” which provides that piece. (Also ssh tunneling.) 2. SQLite is not well-tuned for highly concurrent access. This is only a problem if you have frequent simultaneous commits. I don’t mean that two commits run concurrently occasionally during the workday, I mean high levels of sustained concurrent access. If that is not happening on your Fossil repository, you don’t need a highly-concurrent DBMS as the Fossil data store. With those two weaknesses eliminated as irrelevant to this particular application, there is no reason not to use SQLite and plenty of reason to use it. I suspect that if you reworked the Fossil internals to use a different DBMS engine that Fossil would run considerably slower for almost all current users of Fossil. Until you get to dozens or more concurrent accesses, the advantages of the big client-server DBMSes aren’t going to show up for Fossil. (I say that as one who has migrated code from MySQL to SQLite and observed a 2x speed increase because the application no longer has all that client-server IPC overhead.) > 5/ And when a project uses the word "steal" I have a big doubt… That’s a perfectly good idiomatic use of English. It does not mean what you think it does. Please do not criticize other people’s use of English until you have mastery of it yourself. I’m not trying to be unkind, I am just telling you that you have no basis to be criticizing drh’s use of the English language given your demonstrated skill level. (Be assured that I will not criticize your use of French. :) ) > 6/ Ask yourself why people stay with Git/Mercurial … Easy: network effects. https://en.wikipedia.org/wiki/Network_effect > b) A fossil release 1.37-rocksolid or 1.37-LTS without compilation problems We can’t fix problems if you don’t tell us what you’re running into. I just did a search on this mailing list for your email address, and I can’t see any messages detailing your compilation problems. > c) A strategy for fossil roadmap. Already done: https://www.fossil-scm.org/index.html/info/0e047901c2f4a07d8110f7bb9a94c92b56202700 > d) A minimal understanding of Fossil users needs So tell us: what are your unmet needs? > (Marketing and stuffs like that). Marketing is not the correct word if you mean to talk about improving Fossil to meet user needs. Market research is part of it, but that’s only a tiny part of marketing. I believe you should be talking about community management, not marketing. That’s what we’re doing here, right now. It is why I am answering your email instead of ignoring it. > e) A fossil that do run nicely as it is with git that I do use. Have you tried the nick.lloyd-git-interop branch? https://www.sqlite.org/debug1/timeline?r=nick.lloyd-git-interop _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
