5 ms·

>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

>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.

soerxpso 3y ago
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.
- somenewaccount1 3y ago
  Which is why I said he should be more upfront about it. I had to find that statement buried after 30 minutes of reading how amazing fossil was.
- ezekiel68 3y ago
  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] [0] https://blog.melski.net/2013/12/11/update-scons-is-still-really-slow/ https://blog.melski.net/2013/12/11/update-scons-is-still-rea...
oxfordmale 3y ago
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.
whateveracct 3y ago
"Scaling well" isn't table stakes. it's a tradeoff.
dan-robertson 3y ago
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.
wodenokoto 3y ago
Everybody uses git as a cathedral style system by way of github/gitlab. So all things equal, it should scale just as well as a github project.
nmz 3y ago
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 [0]: https://fossil-scm.org/home/doc/trunk/www/stats.wiki https://fossil-scm.org/home/doc/trunk/www/stats.wiki [1]: https://fossil-scm.org/home/timeline https://fossil-scm.org/home/timeline
- glandium 3y ago
  There is something fishy with the repo on github. git repack -a -f -d du -sh .git 65M .git 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. Also: git gc --aggressive du -sh .git 42M .git
  - nmz 3y ago
    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.
gardenhedge 3y ago
Please read the article: This article is not a comparison between Fossil and Git. This article is not advocating that you switch your projects away from Git.

soerxpso 3y ago

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.

somenewaccount1 3y ago
Which is why I said he should be more upfront about it. I had to find that statement buried after 30 minutes of reading how amazing fossil was.
ezekiel68 3y ago
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] [0] https://blog.melski.net/2013/12/11/update-scons-is-still-really-slow/ https://blog.melski.net/2013/12/11/update-scons-is-still-rea...

oxfordmale 3y ago

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.

whateveracct 3y ago

"Scaling well" isn't table stakes. it's a tradeoff.

dan-robertson 3y ago

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.

wodenokoto 3y ago

Everybody uses git as a cathedral style system by way of github/gitlab. So all things equal, it should scale just as well as a github project.

nmz 3y ago

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 [0]: https://fossil-scm.org/home/doc/trunk/www/stats.wiki https://fossil-scm.org/home/doc/trunk/www/stats.wiki [1]: https://fossil-scm.org/home/timeline https://fossil-scm.org/home/timeline

glandium 3y ago
There is something fishy with the repo on github. git repack -a -f -d du -sh .git 65M .git 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. Also: git gc --aggressive du -sh .git 42M .git
- nmz 3y ago
  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.

gardenhedge 3y ago

Please read the article: This article is not a comparison between Fossil and Git. This article is not advocating that you switch your projects away from Git.