>Git focuses on individual branches, because that is exactly what you want for a highly-distributed bazaar-style project such as Linux. Linus Torvalds does not want to see every check-in by every contributor to Linux: such extreme visibility does not scale well. Contrast Fossil, which was written for the cathedral-style SQLite project and its handful of active committers
Ugh...so after all that fanfare of how amazing fossil is, the author admits it just doesn't scale well. I was wondering how that "see it all" approach worked for a busy repo, and now I know, it just doesn't.
I love SQLite, and glad the primary author is happy working on it with fossil. I think if he published it's largest downfall first, it might gain more adoption to folks that could actually use that feature.
Personally I see "doesn't scale well" as a feature, if I'm evaluating something to use on a personal or small project. Tools with clear limits on what they're not for usually have a more polished experience for what they are for.
In that case you might really love "...SCons, a popular Python-based build tool. In a nutshell, my experiments showed that SCons exhibits roughly quadratic growth in build runtimes as the number of targets increases" [0]
I think [0] indicates that it does scale quite well, you can even test by comparing the 2. You can go from cloning to pushing on a repo in half the time. There's branches as well, so while the /timeline[1] seems too busy, you can always drop back to a forum or the bug tracker, which it has already.
time fossil clone https://fossil-scm.org/
time git clone https://github.com/drhsqlite/fossil-mirror
My results were
fossil
time > real 5m43.120s user 2m56.532s sys 0m48.246s
ls -lh > 60M fossil-scm.fossil
git
time > real 10m35.043s user 5m58.427s sys 1m10.555s
du -sh fossil-mirror/.git/ > 829M
It's also significantly faster to clone after the repack:
time git clone --mirror https://github.com/drhsqlite/fossil-mirror
65.10s user 21.22s system 35% cpu 4:05.92 total
time git clone --no-local fossil-mirror fossil-no-repack
26.92s user 2.99s system 155% cpu 19.190 total
git -C fossil-mirror.git repack -a -f -d
time git clone --no-local fossil-mirror fossil-repack
5.42s user 1.18s system 211% cpu 3.121 total
Edit: took new measurements with --mirror on the first clone so that the "local" clones actually get all the branches.
I imagine fossils internal git export function is not robust. Even when you {fossil git export} the repo, you still get a much bigger .git than fossil (20mb more), with errors on some checkouts. Repacking doesn't do much either in this case, so the functionality changes.
Plenty of tech companies have massive monorepos which large numbers of people contribute to. I don’t know how easy it is for one person to see another’s branch though. So: maybe it can scale, at least somewhat, with a more centralised system.
I have a love hate relationship with Git. It is current used for a lot of purposes it was never designed for by Torvald. It is time for something better, unfortunately Fossil isn't likely going to be a Git successor.
Ugh...so after all that fanfare of how amazing fossil is, the author admits it just doesn't scale well. I was wondering how that "see it all" approach worked for a busy repo, and now I know, it just doesn't.
I love SQLite, and glad the primary author is happy working on it with fossil. I think if he published it's largest downfall first, it might gain more adoption to folks that could actually use that feature.