For what it’s worth, SVN is a much simpler object model compared to Git, which makes it easier to understand.
It’s centralized rather than distributed like Git is, which has some disadvantages. Most operations require access to the server, as opposed to Git where you usually have a copy of the entire repo and can work offline. Git users can clone the repo from other users rather than relying on a centralized server.
On the other hand, a centralized server also simplifies some things. For example, instead of commit hashes, SVN has revision numbers, which are natural numbers that start at 1 and are incremented for every commit. A lot of software that used SVN used to use the revision number as part of the version or build number.
Git is definitely the source control system to choose today, but SVN can still have its place.
My first SWE job out of college in 2019 they were still using SVN because none of the seniors could be bothered to learn how to use git.
The “well this is how we’ve always done it” attitude had a death grip on that place
For what it’s worth, SVN is a much simpler object model compared to Git, which makes it easier to understand.
It’s centralized rather than distributed like Git is, which has some disadvantages. Most operations require access to the server, as opposed to Git where you usually have a copy of the entire repo and can work offline. Git users can clone the repo from other users rather than relying on a centralized server.
On the other hand, a centralized server also simplifies some things. For example, instead of commit hashes, SVN has revision numbers, which are natural numbers that start at 1 and are incremented for every commit. A lot of software that used SVN used to use the revision number as part of the version or build number.
Git is definitely the source control system to choose today, but SVN can still have its place.
For those reasons, I choose mercurial over git whenever I can.
SVN is fine for most corporate workflows. Your project is probably not anything like Linux.