> Fossil was meant to be a 'lite' DVCS
Fossil was meant to support the needs of SQLite, one of the most popular and actively-developed code bases in the world. If Fossil can meet its needs, chances are good that it can meet your project's needs, too. There are very few NetBSD-scale projects out there, compared to the number that are plenty fast under Fossil.
And yes, I'm aware that you could list hundreds of projects at that scale, but I believe I could find millions software projects smaller than that. If you try to argue against this point, you'd be arguing a 0.01% type of position. I'm happy with Fossil going after the other 99.99%.
> Hell, it uses SQLite as its storage backend.
This is a problem how?
The biggest single problem with SQLite from a performance standpoint is that it doesn't have row-level locking, limiting its use in concurrent systems. SQLite has multiple-reader, single-writer concurrency, but multiple writers to a single DB file serialize their writes to a single table. SQLite will let multiple writers can modify separate tables at the same time, but I'm going to assume Fossil has some usage pattern that requires that all commits to hit at least one common table.
According to NetBSD's source-changes mailing list there are only about forty commits per day, so even at that scale, concurrency is simply not an issue.
Projects like NetBSD don't get to be behemoths over night. It takes 40 commits per day for 25 years to make that happen.
SQLite's other big limitation is that it isn't a client-server DBMS, so when you need multiple clients over the network to access the DB, you need some intermediary to provide that access. The naive approach is to use a networked file system, but this is likely to cause problems. But we don't have that problem with Fossil: we have fossil server, which exposes the DB over HTTP. Since a single process is manipulating the central DB, which is a local file to it, there can be no locking problem. If by some small chance two users need to commit at the same time, fossil server will serialize the commits.
> It's a lovely DVCS otherwise.
I agree. The vast majority of the users of Git today could run just as well on Fossil.