You don’t need to install SQLite to use Fossil, as Fossil already contains the (newest) version of SQLite, given that both tools come from the same developer.
In my experience, Git is harder to use than Fossil and if shit hits the fan, it is much harder to unshit the fan. There are reasons why there are numerous tutorials and books about how to tame Git. I don’t want to have to tame the tools that I use every day.
And yes, most tools are not Linux. Linux is a huge bazaar (with one BFDL, but that’s optional). Most real-life projects are a cathedral though, and Git just doesn’t mirror this.
I’m not sure I’d construe a manual you can find, or a variety of guides, as a negative. :) most days my usage of git consists of “pull, commit, push, merge” in different orders. You might be overestimating how much effort goes in to managing the tool.
Most of my professional experience has been working on projects that consist of multiple teams of between 4-6 developers, and between 5 and 40 teams. I’m not entirely sure what you mean about git not mirroring the development patterns of most “real life” projects.
“Real” projects are frequently developed by groups of people working on the same goal adjacent to other groups working on related but distinct goals.
You don’t need to install SQLite to use Fossil, as Fossil already contains the (newest) version of SQLite, given that both tools come from the same developer.
In my experience, Git is harder to use than Fossil and if shit hits the fan, it is much harder to unshit the fan. There are reasons why there are numerous tutorials and books about how to tame Git. I don’t want to have to tame the tools that I use every day.
And yes, most tools are not Linux. Linux is a huge bazaar (with one BFDL, but that’s optional). Most real-life projects are a cathedral though, and Git just doesn’t mirror this.
I’m not sure I’d construe a manual you can find, or a variety of guides, as a negative. :) most days my usage of git consists of “pull, commit, push, merge” in different orders. You might be overestimating how much effort goes in to managing the tool.
Most of my professional experience has been working on projects that consist of multiple teams of between 4-6 developers, and between 5 and 40 teams. I’m not entirely sure what you mean about git not mirroring the development patterns of most “real life” projects.
“Real” projects are frequently developed by groups of people working on the same goal adjacent to other groups working on related but distinct goals.
Most groups of people who write code have one person to report to.