[flagged]
Code review happened informally "after the fact", usually as the first thing in the morning when updating (each person simply looked through the changes of other people in the part of the project they felt responsible for - usually those changes were no surprises because people talked to each other before doing this).
"Post-commit" breakage was surprisingly rare, and when it happened it was quickly fixed. One just was a bit more careful checking for errors before committing changes.
I cannot imagine how this scenario could work with git though.
I cannot image how this scenario could not work with Git†. Maybe I’m missing something important about Subversion, but it’s also just plain old version control. Nothing fancy like Darcs.
†: Granted, there is a (theoretical) point where the frequency of pushes becomes so high you can no longer reasonably work on a single branch.
Both models have advantages and disadvantages, but for many people working on the same branch the centralized model is arguably better.
(in the end, both Github and Gitlab workflows mainly try to put more 'centralization' back into git)
If you don't branch and directly push what you commit, there's little difference between SVN and Git.
Working exclusively on branches and then merging into a common main branch pretty much fixes this problem though (that's why the PR workflow make a lot more sense in git than svn).
We do that on our CI repo because of many tiny changes of unrelated parts that otherwise just made almost every second commit into a merge
exactly the same as with SVN ? The one feature I could see it lacking is ability to lock file in SVN but otherwise "single master repo" work on SVN and Git is very similar