Mozilla Firefox – Official GitHub repo

> They learn a set of narrow workflows and never explore beyond.

And tbh, that's how it should be for a version control system. Before git with its byzantine workflows and a thousand ways to do the same thing, version control (e.g. svn) was a thing that's just humming along invisibly in the background, something that you never had to 'learn' or even think about, much like the filesystem.

I don't need to know how a filesystem works internally to be able to use it.

And having a centralized store and history helps a lot to keep a version control system conceptually simple.

svn was not 'humming' unless you confined yourself to a very narrow set of functionality, e.g. merging was best left to experts.

You don't need to learn how git works internally to be able to use it. You need to know a lot about filesystems in order to use them: Folders, files, symbolic links, copy, cut, paste, how folders can exist on different devices, etc. There's just a tonne of assumed knowledge regarding them, and it's very obvious when you meet someone that doesn't have it (regular people often don't have all it).

Subversion also isn't some thing humming along invisibly in the background, it has its own quirks that you need to learn or you'll get stung.

In a centralized version control system with a single history, branching and merging is also much less important.

In git, working on your own branch is essential to not step on other people's feet and to get a clean history on a single main/dev branch (and tbf, git makes this easy for devs and text files). With a centralized version control system, both problems don't even exist in the first place.

When we did game development with a team of about 100 peeps (about 80 of those non-devs, and about 99% of the data under version control being in binary files) we had a very simple rule:

(1) do an update in the morning when you come to work, and (2) in the evening before you leave do a commit.

Everybody was working on the main branch all the time. The only times this broke was when the SVN server in the corner was running full and we either had to delete chunks of history (also very simple with svn), or get more memory and a bigger hard drive for the server.

svn was a nightmare when it came to handling conflicts. So at least for me, humming in the background wasn’t the term used for it at work.

Have you ever actually used svn?

Yes for about 18 years(?) in the context of game development (I don't exactly remember when we had switched from cvs to svn, but it must have been around 2003..2005) in teams up to about 100 people, working copy sizes up to about 150 GB (with most of the data being binary game asset files), and everybody working on trunk (we only used branches for releases which were branched off trunk but never merged back, only cherry-picking bugfixes from the main into release branches as needed).

We used TortoiseSVN as UI which worked well both for devs and non-devs.

With this sort of setup, git would break down completely if it weren't for awkward hacks like git-lfs (which comes with its own share of problems).

This was only for true before svn 1.5 (before it had 'merge tracking'). Also, branching and merging by far wasn't as essential in svn as it is in a decentralized version control system like git. In a centralized version control system it works perfectly well to do all development in the main branch, and only branch off dead-end 'release branches' which are never merged back.

Tbh, I really wonder where the bad reputation of svn is coming from. Git does some things better, especially for 'programmer-centric teams'. But it also does many things worse, especially in projects where the majority of data is large binary files (like in game development) - and it's not like git is any good either when it comes to merging binary data.

Interesting. At game companies I worked at we generally used version control solutions that easily allowed storing code and assets together, such as Perforce and Alienbrain.