I took a look at the Fossil website and still don’t get this: how do remotes work, and how would Fossil’s version of remotes prevent the main server outage from stopping global VCS collaboration? I’m sure there’s a good answer but I can’t find it from the website.
“The standard tool” is not a constant. When I started programming with other people, CVS was “the standard tool”.
There is also the following consideration: Most VCSs work very similarly. It makes no difference to anyone I can think of which VCS they should use. Why would someone who can write “git pull” suddenly despair of (for example) “fossil update”?
Git also has numerous disadvantages for me, including the improvable merging, the contradictory command line commands, the cluttering of the .git folder with numerous metafiles and so on. What’s wrong with using the best tool for the job and not the one that “everyone uses”? The supposed advantage that everyone already knows Git (haha, who really “knows” Git?) is outweighed by its disadvantages in my opinion.
Fossil, to stick with this example, also has some advantages for me as an administrator: Each repository is a single SQLite file (easy to backup, easy to repair, easy to host - without complicated infrastructure, a web server is enough).
We very clearly work in different professional environments. :)
In no particular order:
Administrating a git server is similarly trivial. A repository is a folder (easy to backup, easy to repair, easy to host), and setting up a new server usually a matter of ssh key management. Don’t even need to install sqlite or anything beyond the git package. Or, because the tool has wide support, you can install a wide selection of tools that manage it for you, or use a free hosting service, or a paid one.
I’m startled that you would say you can’t think of anyone who would care. My entire professional experience has been developer stories about bad jobs often include details about using old or esoteric VCS systems, usually met with “ew” or “wtf” comments. Sets the flavor of the story.
Personally, in a business environment, I would take using anything except git for the org as a red flag. It’s a sign that someone in leadership at the company values doing things unrelated to the core mission “their way” above doing it the easy or “paved path” way.
The standard tool is indeed not constant. Before git existed, using CVS would have been the better choice, as well as for years afterwards until it had clearly been usurped. Most projects aren’t Linux when it made the switch to git.
You joke that no one really “knows” git, but… This is literally the first time I’ve ever seen a fossil command. I just searched for “fossil manual” and I get analog watches. It’s not even available in any of my systems package managers.
Developer familiarity is a big advantage that I think you’re downplaying in comparison to “there are metadata files in .git”, which I don’t know has ever been relevant to me in any significant way.
(Also, I thought the different systems all work basically the same? 😛)
I’d handily agree people should be using the best tool for the job. Familiarity and ease of use are significant factors in what makes a tool better.
Ability to integrate with other tools is also a major factor. Setting up continuous integration or code review tools with git is trivial with any number of different systems.
What are any of the tools you’re using doing better than git? The biggest selling point you’ve shared for fossil is that it’s functionally similar to git, and that it has better merging. I can’t find anything related to merge conflicts outside of years old forum posts, and barely anything relating to merges at all, so I’m not entirely certain what makes it “better”.
If it’s biggest advantage is that it’s similar enough to git that you can pick it up fast, why wouldn’t I just use git?
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.
Fossil, mostly, with some Darcs and SCCS thrown in the mix. Some of my older stuff still resides on SVN (and is perfectly reachable right now).
I think I only have one project on GitHub that’s not only a mirror. This incident reminds me that this was meant to be a temporary solution.
How do you even know darcs
The internet spoiled me.
I took a look at the Fossil website and still don’t get this: how do remotes work, and how would Fossil’s version of remotes prevent the main server outage from stopping global VCS collaboration? I’m sure there’s a good answer but I can’t find it from the website.
It doesn’t.
Why?
How does fossil or svn protect you from a remote server going down making it’s contents unavailable?
Are those advantages worth others not knowing how, or caring to bother, to access or contribute to your software?
What are you gaining by eschewing what is effectively the standard tool?
“The standard tool” is not a constant. When I started programming with other people, CVS was “the standard tool”.
There is also the following consideration: Most VCSs work very similarly. It makes no difference to anyone I can think of which VCS they should use. Why would someone who can write “git pull” suddenly despair of (for example) “fossil update”?
Git also has numerous disadvantages for me, including the improvable merging, the contradictory command line commands, the cluttering of the .git folder with numerous metafiles and so on. What’s wrong with using the best tool for the job and not the one that “everyone uses”? The supposed advantage that everyone already knows Git (haha, who really “knows” Git?) is outweighed by its disadvantages in my opinion.
Fossil, to stick with this example, also has some advantages for me as an administrator: Each repository is a single SQLite file (easy to backup, easy to repair, easy to host - without complicated infrastructure, a web server is enough).
We very clearly work in different professional environments. :)
In no particular order: Administrating a git server is similarly trivial. A repository is a folder (easy to backup, easy to repair, easy to host), and setting up a new server usually a matter of ssh key management. Don’t even need to install sqlite or anything beyond the git package. Or, because the tool has wide support, you can install a wide selection of tools that manage it for you, or use a free hosting service, or a paid one.
I’m startled that you would say you can’t think of anyone who would care. My entire professional experience has been developer stories about bad jobs often include details about using old or esoteric VCS systems, usually met with “ew” or “wtf” comments. Sets the flavor of the story.
Personally, in a business environment, I would take using anything except git for the org as a red flag. It’s a sign that someone in leadership at the company values doing things unrelated to the core mission “their way” above doing it the easy or “paved path” way.
The standard tool is indeed not constant. Before git existed, using CVS would have been the better choice, as well as for years afterwards until it had clearly been usurped. Most projects aren’t Linux when it made the switch to git.
You joke that no one really “knows” git, but… This is literally the first time I’ve ever seen a fossil command. I just searched for “fossil manual” and I get analog watches. It’s not even available in any of my systems package managers.
Developer familiarity is a big advantage that I think you’re downplaying in comparison to “there are metadata files in .git”, which I don’t know has ever been relevant to me in any significant way.
(Also, I thought the different systems all work basically the same? 😛)
I’d handily agree people should be using the best tool for the job. Familiarity and ease of use are significant factors in what makes a tool better.
Ability to integrate with other tools is also a major factor. Setting up continuous integration or code review tools with git is trivial with any number of different systems.
What are any of the tools you’re using doing better than git? The biggest selling point you’ve shared for fossil is that it’s functionally similar to git, and that it has better merging. I can’t find anything related to merge conflicts outside of years old forum posts, and barely anything relating to merges at all, so I’m not entirely certain what makes it “better”.
If it’s biggest advantage is that it’s similar enough to git that you can pick it up fast, why wouldn’t I just use git?
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.