On Tue, 21 Nov 2017 16:42:56 -0700 Warren Young <war...@etr-usa.com> wrote:
> > This seems more like a complaint about the user interface. > > How does that observation get us to a different solution? Because you then focus on tweaking the UI to make it better, rather than just stuffing support for other VCSes because of a few complaints about the UI. > If someone has been using Git for years and I point them at my fine > Fossil repository, they’re not going to be happy switching, even if > they do eventually agree that Fossil is better. That transition cost > must still be paid. > > What many of my public repos’ users want is Git, and I’m refusing > (today) to give it to them. > > This proposed feature set might well fix that problem, with zero > effort on my part. You clearly have very whiney users. Fossil supports downloading entire checkins in zip and tarball archives, so your users can just do that. As far as I can tell, there is no problem. They can just download Fossil and clone, then export to Git. It may be lossy, but Git!=Fossil. > > What is your alternative? Force the world to switch to Fossil? Tell > the Git fans to pound sand? My alternative is to just use the right tools for the job. Sometimes that is Fossil, sometimes that is Git, and sometimes that is Subversion. > This proposal seems like a good way to enlarge the Fossil user base > by leveraging the same network effects that today work against Fossil. So you are suggesting compromise Fossil's code maintainability and simplicity just for the sake of marketing values? > > > Subversion should implement native Git support, > > and Mercurial should implement native CVS support. > > The other VCSes will have to come to whatever accommodation with the > realities of the Git network effects their developer communities are > willing to strive for. And Fossil is no different. > Someone probably once told him it’s too difficult to implement a > SQL92 compatible RDBMS, too. I never said it would be too difficult for him, but rather it would introduce unneeded code complexity and bloat. If people want to use Git, they can use Git. Use the right tool for the job. > > You will also find that tool developers may just get rid of existing > > Fossil support (if it ever existed) because oh well, Fossil can > > support Git so no problem. > > I’d bet there are many more tools that support Git but not Fossil > today than those that support Fossil, irrespective of whether they > also support Git. > > If so, it’s a net win, even if it shakes out exactly like you > suppose, which it won’t. What I was trying to say here is that just implementing support for every rinky-dink VCS out there won't expand Fossil's user base by much. Those that want Git will use Git, those that want Subversion will use Subversion. > > > Let's face it, the SQLite single-file storage mechanism has a > > number of other advantages over the pile-of-files methods, even if > > performance isn't one of them. > > I didn’t mean to imply that I thought that was the case, only that we > can’t know until it’s tested, because science. > > We have some science that shows it’s the other way around: > > https://www.sqlite.org/fasterthanfs.html > > The thing is, we don’t yet know how well that test corresponds to the > way Git uses the filesystem. All we know today is that Git tends to > be faster than Fossil for equal workloads, even when things like > repo-cksum are accounted for. And how will you test this out anyway? Git uses the file system, meaning any performance comparison with Git will depend entirely on what file system is in use. > If that seems like a non sequitur with respect to Fossil, I’d be > interested to see benchmark results that show any common use case > where Fossil’s performance is dominated by time spent *outside* > SQLite code. Lacking such data, I’ll continue to assume that there’s > little point optimizing Fossil proper. The same effort spent > optimizing SQLite and the SQL that Fossil gives to SQLite is time > better spent. You make a good point here, and I agree. SQLite is the majority of Fossil's code base. It may be worth looking at queries to see how they can be optimised as well. > If you do come up with such a benchmark, and it involves the network, > then be sure to account for the time spent waiting for network I/O > separately, unless reworking Fossil somehow reduces time spent > waiting on the network. A 10 ms HTTP transaction where 999 µs of > that is spent in Fossil and 1 µs is spent in SQLite doesn’t count as > “dominated by Fossil code.” Until you get the network time down > from the 9 ms in this made-up example to more like 3 ms, there’s > little point worrying about the Fossil contribution to the > transaction time. True, but I was thinking more in terms of local working directories (commit/merge/etc rather than pull/push/sync/etc). > Infrastructure software like Fossil generally needs to be able to > compile on ~10 year old systems. That means someone is probably > still building Fossil today using Visual C++ 2005, which had terrible > C99 support and likely supported little that eventually appeared in > C11 aside from features that C borrowed from C++. > > SQLite made up roughly half the Fossil C code base the last time I > checked, and it not only needs to build 10 year old systems, but many > of those are *embedded* and not served by any of the Big Four C > compilers. (GCC, VC++, Clang, and Intel.) > > There are some truly bletcherous C compilers in the embedded space. > > I was trying to use one the other day that runs in 4 kwords of > space. Among its long list of misfeatures is that it will recognize > a do/while loop, and it will produce assembly output for it, but the > result either will not assemble or it won’t run correctly if you do > manage to get it to assemble! This particular C compiler only > compiles while/do correctly, and then only on alternate Monday > mornings when the mad god Murphy is too drunk to get out of bed and > meddle. Nobody in their right mind would even consider Fossil (with its in-built web server, wiki, and bugtracker) to run on such a system, so why bother coding for it? Nobody in their right mind would even consider using Git, Subversion, Mercurial, or even Bazaar on those severely limited systems. As for that particular C compiler you are using, it is broken. So is Microsoft's older Visual C compilers. You can use other compilers to compile Fossil and still get reasonable results. I use MinGW-w64/MSYS2 to compile on Windows, which works very well. No need to be stuck with a medieval compiler which can't even support the most basic of C99 stuff since there is enough competition there even on Windows, that Microsoft had to support C99/C11 eventuallly. There is no need for Fossil or SQLite to comply with broken or heavily out-of-date compilers when Fossil/SQLite won't even run on such platforms. BTW, OpenWatcom supports many C99 features and can compile for 16-bit Windows, so perhaps 16-bit Fossil is in order. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
