Instead everyone switched to a "distributed" version control system that is such a pain in the ass it is all now hosted by a single company.
Instead everyone switched to a "distributed" version control system that is such a pain in the ass it is all now hosted by a single company.
Kids these days can't even code at all without chat-GPT, there's a central server hosting the git repo anyway, the whole architecture feels like it was designed for dial-up.
I can't think of anything that was doable 30 years ago compute and bandwidth-wise, that we can't do today due to performance reasons, except client-server source control...
My colleagues evaluated git and thought it was too complicated. A few years and a lot of employments later, they’re all using git. I don’t know if it was peer pressure from enough young recruits, but the verdict is clear: git is better than SVN.
A github server is much easier to set up than a subversion server. The reason people use github is because it's free, and because it has issue tracking and a wiki and forking which plain git knows nothing about.
And in general I feel that their gh cli tool doesn’t get enough praise. Being able to do easy API calls and queries for use in shell scripts (or just the terminal) is great, and the gh copilot is occasionally useful as a refresher for command syntax, or for deciphering some oddball git command you found online.
It’s a massive beast to tackle, and few people have a reason to. I don’t see anything doing what git does having a chance at competing with it. It requires a paradigm shift and a completely new product/approach to versioning to break the git dominance.
You can't set up a GitHub server.
https://svnbook.red-bean.com/en/1.8/svn.serverconfig.svnserv...
Although...you can set up a Github on-prem server -- or at least this used to be true. Talk to Github Sales and be prepared to write a check.
Oh here we go again. You are wrong my friend. Firing up a basic SVN server is a matter of minutes. You just need to run several simple commands.
My first assignment was to spend several days picking apart an extremely nasty merge conflict from two branches nearly six months diverged. That was a very stupid thing to trust me with, as a major refactor was being blessed by my idiot hands.
Management could not figure out how they wanted to maintain a master/production branch.
Our 'trunk' was the develop branch, and any time we wanted to push to production.... We deleted the master branch and made a copy of develop. Master branch had no history, you had to track it back into develop and hope you found a trailhead from there.
It was a very bad time, and we were left with a very bad product. By the time I left, the codebase was so rotten and broken that we'd abandoned all hope of fixing the deeper issues.
I really hated subversion, but mostly the company was just unbelievably mismanaged. I'm sure you can use SVN in a sane way, just not like this
"Github isn't all git [some features of GitHub are not in Git], but all git is Github [but all features of Git are in GitHub]."
Maybe my interpretation is incorrect?