My first job used SVN and it limited workflows compared to git. Branches are more expensive, so people adapt their workflows. I used git-svn on that job, which allowed me to refactor locally; not a feature available to me or others once pushed.

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.

Many companies host git besides github (gitlab and bitbucket to name two), and you can spin up one of your own in about 1 minute on your hardware or on a private cloud vps.

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 nowadays it offers so much more like the GHAS, codespaces, copilot, actions and workflows etc that companies who get entrenched would need half a dozen different vendors to cover the feature set if they were to migrate from GitHub.

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 absolutely spin up vanilla git on your own machine, but try using it for a week. From some quick Googles it looks like Github has 80% market share of version control with Dollar Store Github (Gitlab) picking up the rest. Everyone uses the pretty tool stack built on top of it because it is overly complex. Git didn't add anything profound that couldn't have been added as a feature to another VCS.

> A github server is much easier to set up than a subversion server.

You can't set up a GitHub server.

The intention I got from @dreamcompiler was that "A git server is much easier to set up than a subversion server.", which I feel is true.

No, this isn’t true. You can deploy your SVN server with ‘svnserve’ in just a few minutes.

https://svnbook.red-bean.com/en/1.8/svn.serverconfig.svnserv...

Yes. Typo on my part.

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.

you can download a VM image of it from their website

> A github server is much easier to set up than a subversion server.

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.

Please, Github is so much more than git hosting. If all it offered was source hosting, no one would care for it.

Github isn't all git, but all git is Github.

False. I'm working on two large distributed projects now in git. Neither has anything to do with github.

I think the meaning of the sentence you're replying to is that GitHub's features are a superset of Git's features which seems true?

"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?

Torvalds liked to code on planes back when you couldn't use the internet and that's just about the only use-case I've ever heard where I agree distributed makes sense.

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

I recently started a new job that uses SVN, one thing that really catches me out is that it doesn't automatically add new files. Is there some easy trick I am missing to tell SVN to automatically track everything recursively under a folder?

Are you using the CLI or something like TortoiseSVN? Tortoise has a fairly intuitive UI for adding untracked files when you commit.

My very first programming job used Subversion. Even as a freshly minted programmer I knew we were using it completely wrong.

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