On Nov 22, 2017, at 7:43 AM, bytevolc...@safe-mail.net wrote:
>
> 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.
The Fossil vs Git UI situation has been studied before. There’s a tremendous
amount of logical mismatch between the two, such that commands for one often
cannot be translated 1:1 to the other.
Just as a single example:
$ fossil ci
is not at all the same thing as
$ git commit
A better approximation is:
$ git commit -a && git push
And even then I’m sure I’m missing some details.
Now, here we have an example where Fossil is far clearer, as is the typical
case, but that won’t make all the Git fans you show this to squee and insist
that their projects switch to Fossil.
I’m reporting results here, not speculating. I’ve tried it, and some kind of
dismissal is almost always the result. Why do you suppose that is?
What keeps these people using Git are network effects. Most people decide that
it’s better to put up with its horrible CLI or tie themselves to proprietary
GUIs/web services — most prominently, GitHub — rather than lose out on all the
benefits they get by being in the Git world.
We’ve been to this party before. Linux vs Windows, Pascal/D/ObjC/Go/Rust/...
vs C, etc., etc. “Better” doesn’t always win.
>> What many of my public repos’ users want is Git, and I’m refusing
>> (today) to give it to them.
>
> You clearly have very whiney users.
I’d say I have normal users: they want maximum results for minimum effort.
As do I. Since I run the project server, what I say generally goes, but I
ignore my users’ wishes at peril of losing my user base, thus risking a waste
of my time writing software that no one will use.
There is not black or white here. There is only gray.
> Fossil supports downloading entire
> checkins in zip and tarball archives
I often end up hand-constructing such URLs for my users to click, because they
can’t be bothered to dig through the UI to figure it out.
Here we have a case where Git is actually faster and clearer:
$ git clone https://example.com
vs.
1. Visit https://example.com
2. Click Timeline (and how would my users know to do that?)
3. Click checkin ID.
4. Find and click Tarball link
5. Unpack the tarball
Then they must do all 5 steps again every time there is a new version they
want, vs:
$ git pull
Fossil often can’t get to the simplicity of Git here for two reasons:
1. Fossil may not be in the end user’s stock OS package repo. (e.g. RHEL,
CentOS.)
2. If it is, it may be far too outdated to even work with the central repo.
(e.g. Debian, Raspbian.)
Thus we have to point users at precompiled binaries or instruct them in
building from source, all of which makes Fossil look even more complicated than
Git, when day-to-day, the reverse is true. But you only realize that *after*
you get Fossil up and running on your system.
>> 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?
I’m just cheerleading here. It’s drh’s call what he spends his time on. I
trust his judgement.
> implementing support for
> every rinky-dink VCS out there won't expand Fossil's user base by much.
Of course not. But adding Git support alone will expand Fossil’s applicability
tremendously. We could pick up probably 90% of the public source repositories
with that one move. Adding Hg would probably add most of the remaining 10%.
>> 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.
By controlling variables, as any good scientific experiment does. Here, that
means using the same filesystem, disks, etc. If Fossil is reworked to use a
Git-compatible pile-of-files repository format and performance doesn’t improve,
then either:
1. That wasn’t the source of the difference, so now we can check it off the
list of things to look at; or
2. There is an important difference in the implementations, which will now be
easier to find, since both code bases are trying to achieve precisely the same
end.
Contrast the state of things today, where comparisons are almost pointless,
because Git and Fossil are comparable only at a skin-deep level. They’re both
DVCSes, and that’s about the extent of the similarity. How then can you know
why one is faster than the other?
> Nobody in their right mind would even consider Fossil (with its
> in-built web server, wiki, and bugtracker) to run on such a system
There’s a wide rainbow between my 4 kWord C compiler and modern GCC.
It wasn’t that long ago that I worked out a plan, here on the mailing list, for
a way to get a good portion of Fossil onto a PDP-11. I didn’t get any
responses that told me why it was impossible.
I suspect you have too narrow a view of what being in one’s right mind is. It
takes all kinds of crazy to make up today’s F/OSS world.
"Here's to the crazy ones, the misfits, the rebels, the
troublemakers, the round pegs in the square holes…
the ones who see things differently — they're not fond
of rules… You can quote them, disagree with them,
glorify or vilify them, but the only thing you can't do
is ignore them because they change things… they push
the human race forward, and while some may see them as
the crazy ones, we see genius, because the ones who are
crazy enough to think that they can change the world,
are the ones who do.”
— Steve Jobs
> As for that particular C compiler you are using, it is broken.
Therefore…what? No good work can be done with such compilers? The platforms
they support must be relegated to the dustbin of history?
Would you write off the entirety of the retrocomputing and retrogaming
movements plus a good chunk of the embedded space just to defend your idea of
what a “good” C compiler must be?
I’m all for standards and progress, but I also recognize that we cannot always
drag elements of the past up to current standards, and that there is value in
past systems and purposely limited modern systems.
Much of the problems we’re having with IoT these days comes from trying to put
a 32-bit processor running a multitasking GCC and Linux based OS into
lightbulbs.
> 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.
You’re focusing on my one extreme example and ignoring the rainbow between that
and your apparent conception of minimal acceptable platform.
I expect I could get SQLite and Fossil to run on a PIC32, for example. The
current version of Microchip’s XC32 compiler for that chip family only supports
C89 and some C99 features. It also supports up to C++03, which means it might
implicitly understand some C11 as well, but certainly not all of it.
I don’t need to do that today, but I’d prefer that you don’t preclude me doing
it in the future just because you want to require C11 to compile SQLite and
Fossil.
Infrastructure software should live by different rules than user-facing
software. If you are developing software for a company whose marketing
department decides that targeting only Windows 8 and 10 is the best decision,
then by all means, use C11 or C++14 exclusively; you can afford it.
> BTW, OpenWatcom supports many C99 features and can compile for 16-bit
> Windows, so perhaps 16-bit Fossil is in order.
I think Microsoft’s unmcommon success at maintaining backwards compatibility
makes 16-bit Windows an uninteresting platform from a retrocomputing standpoint.
More interesting are platforms like the PDP-11, SNES, etc., which require
simulators/emulators to run software for those machines on modern hardware.
Programmers wanting to produce new software for those machines must either use
compilers of the day or retarget current tools for them, often dropping
features along the way to squeeze into the old footprint.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
