Re. integrated wiki: when i first saw fossil (Christmas break of 2007) two features made it a killer app for me: wiki and hosting as a CGI. The wiki aspect has long since taken a back seat to the so-called "embedded docs" feature, where the docs live in the source tree and become first-class SCM citizens. However fossil is, to the best of my knowledge, still the only SCM which is absolutely trivial to host as a CGI, which means it can be hosted on cheap shared hosters just as easily as it can on one's standalone VPS.
As far as "what comes after git," though: git is the SCM needed by the 0.1% (or fewer) of the largest, most-active FOSS projects. Imagine the Linux kernel source tree if its SCM could not remove dead branches - it would quickly become uncloneable under all of that weight. Fossil is not designed to scale to projects of that size. Fossil is, however, an ideal SCM for that 98%+ of remaining projects which fall into the size categories of personal/small/medium.
"Fossil is, however, an ideal SCM for that 98%+ of remaining projects which fall into the size categories of personal/small/medium."
I wonder why so few developers consider the scenario you describe. Git fits the development of Linux. But, a question rarely raised: why is Git considered suitable for small or medium projects?
> A question rarely raised: why is Git considered suitable for small or medium projects?
Quite frankly, _it's not_. There's _absolutely nothing_ ideal about git except for its ability to super-scale to that _exceedingly small_ percentage of projects which need that level of scaling. That's its _one and only_ killer feature. If it weren't for github and its ilk, git would be just another second-tier tool like the rest of the SCMs. Unlike every(?) other SCM, fossil doesn't require 3rd-party tools to host over CGI: that's built right in to it and CGI works on even the cheapest of shared-hosting platforms, so no equivalent of github is required in order to host one's own repositories.
Granted, as a long-time fossil dev and advocate, i'm _severely_ biased in this regard, but there's are _reasons_ i prefer fossil over git, why i use it for _all_ of my own projects (fossil.wanderinghorse.net), and why i support and advocate for it (just not for that small tier of "uncommonly large" projects, as fossil has, quite frankly, no business being used there).
Network effects, and that once many people get the hang of using git "well enough" they'd rather put up with it's annoyances than take the time to learn something that's marginally better..
It's probably why so many people want to learn/use Hadoop and whatever else Big Tech is using to address their massive scale. Premature optimization and resume-driven development.
I actually love git (even for small projects) but it's because I've been using it for so long now; I suspect if I learned another DVCS I'd be using it in isolation, and git works just fine for me
Re. integrated wiki: when i first saw fossil (Christmas break of 2007) two features made it a killer app for me: wiki and hosting as a CGI. The wiki aspect has long since taken a back seat to the so-called "embedded docs" feature, where the docs live in the source tree and become first-class SCM citizens. However fossil is, to the best of my knowledge, still the only SCM which is absolutely trivial to host as a CGI, which means it can be hosted on cheap shared hosters just as easily as it can on one's standalone VPS.
As far as "what comes after git," though: git is the SCM needed by the 0.1% (or fewer) of the largest, most-active FOSS projects. Imagine the Linux kernel source tree if its SCM could not remove dead branches - it would quickly become uncloneable under all of that weight. Fossil is not designed to scale to projects of that size. Fossil is, however, an ideal SCM for that 98%+ of remaining projects which fall into the size categories of personal/small/medium.