Holy war mode on ?
You probably know little software, or only a very limited class of software. See Myth #5.
Keeping interconnected applications in single monolithic repo has a lot of benefits over having different repositories. The main benefit is that every revision is set in stone and perfectly reproducible afterwards. It is also possible to do atomic changes to several projects. Just read about why Google does that. SVN allows you to checkout only a few subdirectories of the repo, so monolithic repo does not forbid people to download only what they need. Git sort-of has sparse checkouts, but there are complicated, most likely limited, and etc. Submodules... I'd better never know of their existence ?
Yes, SVN is known for having more conflicts and having worse tools for resolving them. But with trunk-based development, they rarely happen. On the other hand, conflicts are the core nature of all VCS we use. Don't tell tales that conflicts won't happen at all with git.
The same thing happens with git when people work via merge requests. Which is how it is usually done, especially for outer contributors.
Changing VCS won't help you much with not breaking trunk. Unless you are going to work in your private branch for months without merging back, in which case nobody will ever review&accept your merge request due its gigantic size
Yes, and this is very dangerous, because most of developers are poor testers. They will gather bugs in their branches, and then when they consider them "truly stable", merge all these bugs into trunk/develop. And nobody will notice it soon, since everyone is deep in his own branches, branched from develop a month ago.
I prefer following the most widely used practice of game development, when everyone is sitting on trunk, so that all bugs get noticed and fixed quickly. Do you know that in Naughty Dogs artists even have an auto-update script for assets repo? So that when someone commits something, everybody forcibly gets the updated version.
This is a relevant topic due to recent server outages. It is planned that our admin will provide readonly access to current backups to several members, to be sure that the whole TDM knowledge base does not suddenly disappear.
Speaking of normal usage, SVN has zero chance of losing data, since there is no history rewrite. Git, on the other hand, has lots of unsafe ways to edit history, and it is often encouraged. Which provides a good opportunity for users to lose their local history. And in worst case, I guess even remote history can be lost. Recall that git is not a Version Control System, it is a "Stupid Content Tracker". Stupid enough to lose the content it tracks.
Holy war off?
I think the main reasons why SVN stays on TDM are:
Aside from the engine source code repo, we have a few more repos. They contain assets, and migrating them to git would be a disaster. And since they stay on SVN, source code should better stay on SVN too. Avoiding one more VCS is enough reason in itself.
Git is inherently harder to use than SVN. Moreover, it is harder not because it has to be so, but because it was ill-designed. I don't like the idea of forcing complexity onto everyone (including myself BTW). Whoever wants to use git can take the additional complexity onto himself and use git-svn, or any other approach to synchronize SVN with git. Also, we have artists: while usually they don't work with source code repo, sometimes they decide to build the engine themselves.
There are ways to use git locally with SVN. I do this sort of thing myself with hg.
Some time ago I suggested creating an official GitHub mirror for source code repo, with some semi-automatic workflow for accepting pull requests. As far as I remember, nobody was interested. And migration is unlikely to happen.