On Nov 21, 2017, at 3:55 PM, [email protected] wrote:
>
> On Mon, 20 Nov 2017 17:44:49 -0700
> Warren Young <[email protected]> wrote:
>>
>> …muscle memory for both Fossil partisans and for partisans of other
>> VCSes.
>
> This seems more like a complaint about the user interface.
How does that observation get us to a different solution?
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.
What is your alternative? Force the world to switch to Fossil? Tell the Git
fans to pound sand?
This proposal seems like a good way to enlarge the Fossil user base by
leveraging the same network effects that today work against Fossil.
> 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.
> The idea being proposed appears to be that Fossil repositories should
> be able to store artifacts in multiple different formats, which will
> only be a disaster since the "legacy" Git/SVN/CVS clients cannot read
> that kind of repository anyway.
I’m not enough of an expert on any of these file formats to know if the
conclusion follows from the premise. I assume drh is, who proposed it, and
will likely be doing the bulk of the work.
So, let’s just wait and see.
Someone probably once told him it’s too difficult to implement a SQL92
compatible RDBMS, too.
>>> svn > cvs > fossil, often stopping at git or hg. If Fossil could
>>> offer a Git or Hg view of the same data and take pushes losslessly
>>> via that same format, we wouldn’t have to keep blindly hoping that
>>> tool developers would add Fossil support.
>
> 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.
> 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.
Also, realize that you’re talking to a raging Fossil partisan here. You don’t
need to sell me on its virtues.
> Profiling and optimising the most frequently called routines will help.
Do you believe that is not already being done?
How else do you suppose new versions of SQLite regularly come out showing
faster performance for some use case?
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.
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.
> Not coding like it's 1989 and use modern C99/C11 (eg. postpone variable
> declarations, declaring variables in a for(...) loop, uint_XX_t,
> inline, etc) will also help.
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.
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
