4 ms·

Dr. Hipp seems to be trying hard to promote Fossil as superior to Git. Perhaps it is, but that ship has sailed already. He recently commented in an interview th

Dr. Hipp seems to be trying hard to promote Fossil as superior to Git. Perhaps it is, but that ship has sailed already. He recently commented in an interview that Fossil is tailored and perfectly suited for the needs of the SQLite project. That's a strong argument in favor of Fossil and all he really needs to say on the topic.

agbell 5y ago
>"I looked at Git, I looked at Mercurial, and I looked at my requirements and I thought, “You know what? I’m just going to write my own,” so I wrote my own version control system, which is now a project unto itself, and that worked out very, very well, because think, Linus Torvalds wrote Git to support the Linux kernel, and it is perfectly designed to serve the needs of the Linux kernel development community. If you’re working on the Linux kernel, Git is absolutely the perfect version control system. >Now, if you’re working on something else, though, maybe not so much, and so, it’s a perfectly atrocious version control system for working for SQLite. >Fossil is absolutely the perfect version control system for working in SQLite, and I wrote it for that purpose, and so, because I wrote it myself, it exactly meets my needs and is the perfect product for what it’s doing, so by doing things yourself, you control your own destiny, you have more freedom, you’re not dependent upon third parties." https://corecursive.com/066-sqlite-with-richard-hipp/#building-fossil https://corecursive.com/066-sqlite-with-richard-hipp/#buildi...
iso8859-1 5y ago
Why does it matter if he can or cannot capture the majority of that market? The points can still be valid. A few thousand users is still a win for him.
- agbell 5y ago
  Agreed and also it is valuable to not have a total monoculture. It's helpful to have people out and exploring other ways to do things.
- sgbeal 5y ago
  > Why does it matter if he can or cannot capture the majority of that market? Amen to that. FWIW... i've actively contributed to fossil since 2008 and can say with some authority that we (the "regulars" on the project) have never done "PR pushes" for more users. It's simply not how any of us function. We welcome those who stop by, and we're happy to evangelize when approached, but we don't go actively hunting for more users. We're more of a "build it and they will come (or not)" project. Every couple of years someone pops up in the mailing list/forum proposing ways we could gain more users if we'd just do this and that and that other thing, but that's simply not a priority for any of us who actively work on Fossil. Continued work on Fossil is not about dominating the DVCS field (git has, for better or worse, long since done that). As Richard is quoted in earlier responses in this thread, Fossil is, first and foremost, a tool for maintaining sqlite. Similarly, i make use of Fossil for literally all of my own code because it's a great tool for the job, whereas git is... errr... less so. PS: the overwhelming majority of FOSS projects are far closer in size and scope to sqlite than they are to the Linux kernel (for which git was created).
  - mscrnt 5y ago
    > PS: the overwhelming majority of FOSS projects are far closer in size and scope to sqlite than they are to the Linux kernel (for which git was created). It's amusing if not ironic how many comments are something to the effect of "...but how messy and clumsy would the Fossil approach be when working with the Linux kernel that has 1000s of contributors pushing 1000s of commits..." when the sum total of projects approximating the size of the Linux kernel can be counted on one hand, and the authors of such comments are almost certainly not working on such projects. Not to mention the author of Fossil has clearly stated that Git is great for Linux kernel development, and Fossil was not developed for such a project.
thunderbong 5y ago
I didn't see it as such. It felt more like the approach that Fossil has towards maintaining history vs what Git has. I don't quite think it's a race to be won.
pawelmurias 5y ago
That's actually an argument in favor of git. SQLite has literally <= 3 developers.
- SQLite 5y ago
  See https://www.sqlite.org/src/reports?type=ci&view=byuser https://www.sqlite.org/src/reports?type=ci&view=byuser SQLite has had about 33 contributors (after you combine people using multiple login names). But 92% of the commits have been from just two people. 97% from just three people. Then there is a long tail of other contributors. Fossil itself is similar: https://fossil-scm.org/home/reports?type=ci&view=byuser https://fossil-scm.org/home/reports?type=ci&view=byuser - 5 or 10 people account for most of the commits, and then there is a long tail. But aren't most projects like this? A few core developers are responsible for most changes and enhancements, and then there lots of others that might contribute a patch or two here and there? I suspect there exceptions to this (the Linux kernel comes to mind) but I think they are rare. Correct me if I'm wrong.
  - pawelmurias 5y ago
    Sqlite officially does not accept patches or contributions. There are very few projects that are openly hostile to contributors making sqlite unique. To be honest the link you posted shows it seems people have fixed some stuff (it seems mostly security holes and build fixes in the past).
    - SQLite 5y ago
      We accept (quality) patches and contributions from people who have completed the necessary paperwork to put their patches/contributions in the public domain. This restriction is in place so that that SQLite itself can remain in the public domain. If we accept drive-by patches from anonymous users, then SQLite would have to be relicensed as GPL or similar, which would undermine many of its use cases.
      - athms 5y ago
otherme123 5y ago
It sounds to me like promoting SQLite itself. There are lots of people deploying Postgres and friends when their best DB for their case would be SQLite. In the same way, we are all using Git even for microprojects that would be better served with Fossil. I never had the impression of Dr. Hipp saying "Fossil > Git", but "Fossil might fit you better than Git".
protomyth 5y ago
I see it as more of a "don't try to use Fossil as Git or Git like Fossil". If you are just using them for code control for your own project, then this might tell you which fits your style.

agbell 5y ago

>"I looked at Git, I looked at Mercurial, and I looked at my requirements and I thought, “You know what? I’m just going to write my own,” so I wrote my own version control system, which is now a project unto itself, and that worked out very, very well, because think, Linus Torvalds wrote Git to support the Linux kernel, and it is perfectly designed to serve the needs of the Linux kernel development community. If you’re working on the Linux kernel, Git is absolutely the perfect version control system. >Now, if you’re working on something else, though, maybe not so much, and so, it’s a perfectly atrocious version control system for working for SQLite. >Fossil is absolutely the perfect version control system for working in SQLite, and I wrote it for that purpose, and so, because I wrote it myself, it exactly meets my needs and is the perfect product for what it’s doing, so by doing things yourself, you control your own destiny, you have more freedom, you’re not dependent upon third parties." https://corecursive.com/066-sqlite-with-richard-hipp/#building-fossil https://corecursive.com/066-sqlite-with-richard-hipp/#buildi...

iso8859-1 5y ago

Why does it matter if he can or cannot capture the majority of that market? The points can still be valid. A few thousand users is still a win for him.

agbell 5y ago
Agreed and also it is valuable to not have a total monoculture. It's helpful to have people out and exploring other ways to do things.
sgbeal 5y ago
> Why does it matter if he can or cannot capture the majority of that market? Amen to that. FWIW... i've actively contributed to fossil since 2008 and can say with some authority that we (the "regulars" on the project) have never done "PR pushes" for more users. It's simply not how any of us function. We welcome those who stop by, and we're happy to evangelize when approached, but we don't go actively hunting for more users. We're more of a "build it and they will come (or not)" project. Every couple of years someone pops up in the mailing list/forum proposing ways we could gain more users if we'd just do this and that and that other thing, but that's simply not a priority for any of us who actively work on Fossil. Continued work on Fossil is not about dominating the DVCS field (git has, for better or worse, long since done that). As Richard is quoted in earlier responses in this thread, Fossil is, first and foremost, a tool for maintaining sqlite. Similarly, i make use of Fossil for literally all of my own code because it's a great tool for the job, whereas git is... errr... less so. PS: the overwhelming majority of FOSS projects are far closer in size and scope to sqlite than they are to the Linux kernel (for which git was created).
- mscrnt 5y ago
  > PS: the overwhelming majority of FOSS projects are far closer in size and scope to sqlite than they are to the Linux kernel (for which git was created). It's amusing if not ironic how many comments are something to the effect of "...but how messy and clumsy would the Fossil approach be when working with the Linux kernel that has 1000s of contributors pushing 1000s of commits..." when the sum total of projects approximating the size of the Linux kernel can be counted on one hand, and the authors of such comments are almost certainly not working on such projects. Not to mention the author of Fossil has clearly stated that Git is great for Linux kernel development, and Fossil was not developed for such a project.

thunderbong 5y ago

I didn't see it as such. It felt more like the approach that Fossil has towards maintaining history vs what Git has. I don't quite think it's a race to be won.

pawelmurias 5y ago

That's actually an argument in favor of git. SQLite has literally <= 3 developers.

SQLite 5y ago
See https://www.sqlite.org/src/reports?type=ci&view=byuser https://www.sqlite.org/src/reports?type=ci&view=byuser SQLite has had about 33 contributors (after you combine people using multiple login names). But 92% of the commits have been from just two people. 97% from just three people. Then there is a long tail of other contributors. Fossil itself is similar: https://fossil-scm.org/home/reports?type=ci&view=byuser https://fossil-scm.org/home/reports?type=ci&view=byuser - 5 or 10 people account for most of the commits, and then there is a long tail. But aren't most projects like this? A few core developers are responsible for most changes and enhancements, and then there lots of others that might contribute a patch or two here and there? I suspect there exceptions to this (the Linux kernel comes to mind) but I think they are rare. Correct me if I'm wrong.
- pawelmurias 5y ago
  Sqlite officially does not accept patches or contributions. There are very few projects that are openly hostile to contributors making sqlite unique. To be honest the link you posted shows it seems people have fixed some stuff (it seems mostly security holes and build fixes in the past).
  - SQLite 5y ago
    We accept (quality) patches and contributions from people who have completed the necessary paperwork to put their patches/contributions in the public domain. This restriction is in place so that that SQLite itself can remain in the public domain. If we accept drive-by patches from anonymous users, then SQLite would have to be relicensed as GPL or similar, which would undermine many of its use cases.
    - athms 5y ago

otherme123 5y ago

It sounds to me like promoting SQLite itself. There are lots of people deploying Postgres and friends when their best DB for their case would be SQLite. In the same way, we are all using Git even for microprojects that would be better served with Fossil. I never had the impression of Dr. Hipp saying "Fossil > Git", but "Fossil might fit you better than Git".

protomyth 5y ago

I see it as more of a "don't try to use Fossil as Git or Git like Fossil". If you are just using them for code control for your own project, then this might tell you which fits your style.