Comment by jimbob45
2 days ago
SVN has always worked for me. You don’t have to “teach” people SVN because it’s intuitive and works just fine for the 99% case. I wish we would all stop larping as 1337 hackerz and just admit that git is overkill for the vast majority of people.
Another anecdotal data point : I wasted a lot of time trying to figure out SVN too. I think I was using TortoiseSVN FWIW but basically gave up on my two person project
Starting a new repo in SVN is find a server somewhere, if doesn't have SVN install SVN, if it does have SVN deal with whatever politics runs its trunk to find space/define a branch structure for you, and so forth.
It is its own footgun as well, but with git you can git init any directory you want and have a repo. Other than the learning curve of the not particularly well tuned CLI (and there are all sorts of graphical clients today and alternative CLI clients), it's very low barrier to entry to get something/anything in source control.
It's not just "larping as leet hackerz", there are real benefits to git over SVN. There are fewer barriers to entry for small teams and hobby devs, especially in a world with GitHub/GitLab/Sourcehut/and more, but also in the world where maybe a git repo never syncs with any other single machine or is hosted on the barest feature set SAMBA folder or is only ever using email-based PR flows.
git could be easier to teach. git could have a better out of the box CLI. That doesn't mean "git is overkill" especially from the point of view of "needing a whole central server setup just to store multiple versions of a file is overkill". Git is perhaps "underkill", it does the bare minimum as best it can in whatever environment you give it. It's intentionally dumb and stupid (hence its name, to be fair) and it's learning curve is as much because it is "too dumb" than because it "isn't intuitive". I've seen some "intuitive" UIs built on top of it. Another comment here remarked "git isn't a source control system, it's a low level toolkit for building your own" and that's not far from the truth and definitely not far from git's origins (and its name). That's a sort of "underkill". ("One day we'll finally build the right, intuitive high level API." That's basically how git was designed. You don't have to just take my word on that, you can search the old mailing lists for all sorts of interesting discussions and debates on "porcelain" options.)
>Starting a new repo in SVN is find a server somewhere, if doesn't have SVN install SVN, if it does have SVN deal with whatever politics runs its trunk to find space/define a branch structure for you, and so forth.
Many years ago, SVN worked fine for me for single-user projects. I just made my own desktop be the server. But I wasn't publishing my code back then (it's not as if I would have have any effective way to tell people about it anyway). Now I have no idea how the equivalent of "pushing to origin" would have worked.
Around the period I might have adopted SVN I recall it was a huge pain, if not impossible, to install on a Windows desktop; I tried multiple times, failed at each attempt, and eventually gave up. I was also in some labs at the time where we weren't allowed RDP to personal machines or services, or the lab machines just weren't great at it, or both (depending on the exact type of lab class and how worried the professor was of plagiarism), and mostly only had access to dumb sftp systems during the labs. That's when I discovered and fell in love with darcs. Distributed source control is great. Source control that you can push changes to/from the dumbest file systems is a super power. (Just the other year, even, I was using git and a dumb folder share to move source control changes to and from a VM that was firewalled from any network traffic because it had to be.) I miss some of the smarts of darcs still somewhat regularly having adjusted to this timeline where git won handily, but I'm not going back to a centralized source control system and git is "good enough" most of the time.
2 replies →
I agree with your sentiment. I was kind of "forced" to use (and eventually fully migrate to) git because the IDE integration to SVN became more quirky every year. Instead, git is already integrated in IDEs these days.
Clearly you have never needed code search across 50+ SVN repositories before, then. ;)
No, but seriously, I wrote https://andrew-quinn.me/reposurgeon for a reason. While I actually see some big benefits to SVN over git for areas with large binary assets like game development, the tool is just so ancient these days that it's just easier for me to convert SVN repos to git repos and then use those to figure out what I actually need to do. It feels a lot like working with Laplace transforms, translating and un-translating between two not quite equal ways of measuring reality.
That's not even considering that the kinds of companies still using SVN in 2025 tend to have a lot of code to wade through. Serious selection effects in play there -- mostly for good, to be clear.
Working with SVN was terribly slow on any decent size codebase.
svn is perfectly fine and intuitive as long as you never want to branch and merge
huh?
Svn can branch and merge - maybe bit more clunky but still works
SVN is more alien to me than git. Does that make you a LARPing epic hacker?