The source control was so smooth and pleasant that it convinced me that git isn't the be all end all, and the general developer focus was super nice, but some of that tooling was pretty janky, poorly documented, and you had no stack overflow to fall back on. And some of it (like EdenFS), really felt like it was the duct tape holding that overloaded monorepo together (complete with all the jankiness of a duct tape solution).

What you can do with 84000 employees

And kinda horrifying. If something goes wrong, no Google, it's straight to IT

Speaking from my own experience and a few other seniors I work with, you try to recreate solutions you like at those smaller shops. It may not be identical, but you know what's possible.

I came into a company that didn't have a system to manage errors. At my old job, errors would get grouped automatically and work can be prioritized through the groupings. The new company only handled errors when they saw it, by word of mouth.

Immediately went to work setting up a similar system.

Absolutely does. Source: worked for Amazon.

Oh, it impacts indeed. And I would expect that to be partially to keep the devs from hopping away, as they will have a hard time transferring

On the other hand, onboarding is longer and wastes more time and money of the company ¯\_(ツ)_/¯

I still use Parsec for remote, and I don't have any issue with it, it works great and I like it. However, they also did offer a free SDK (Unity plugin) to integrate remote play into your game natively (just like you can have "Invite to Steam Remote Play" button from Steam SDK), which was exactly what we needed - and Steam Remote was never working without issues for us, in comparison to Parsec which worked amazingly well every time we tried it.

I found numerous mentions of Parsec SDK and how easy it is to integrate, but after Unity bought it, I couldn't find it anywhere. Only mention was that if you need it, you should contact them.

So I did that, mentioning that we are a small team of students working on a offline co-op only 2 player game in our free time, and that since Steam Remote wasn't working for us and I have great experience with Parsec, I asked what we have to do to get access to the SDK/Unity plugin.

Unity's answer? Sure, no problem, they will be happy to give us access, with first step being that we pay them 1 000 000$ for it.

Like, wtf? Did they even read the email? How out of touch you have to be, to casually ask a small student team to pay 1 000 000$?

I was trying to say that tools were better about letting us know that another developer was modifying the same file as us, so we would collaborate in advance of creating the conflict.

Rebasing updates the commit ids. It's fine. Commit IDs are only local anyway.

One thing that makes mercurial better for rebase based flows is obsolescence markers. The old version of the commits still exist after a rebases and are marked as being made obsolete by the new commits. This means somebody you've shared those old commits with isn't left in hyperspace when they fetch your new commits. There's history about what happened being shared.

But if not for using submodules, how can one share code between (mono-)repos, which rely on the same common "module" / library / etc.? Is it a matter of "not letting submodules usage get out of hand", sticking to an "upper limit of submodules", or are submodules to be avoided entirely for monorepos of a certain scale and there's a better option?

The manager likes it.

While I'm not using it, since we started our small-team hobby project in git and moving away from it would be a bother, there is one use-case of SVN that would save us a lot of headaches.

SVN being centralized means you can lock files. Merging Unity scenes together is really pain, the tooling mostly doesn't work properly and you have no way how to quickly check that nothing was lost. Usually, with several people working on a scene, it resulted in us having to decide whose work we will scratch and he will do it again, because merging it wouldn't work properly and you end up in a situation where two people each did hundreds or thousands of changes to a scene, you know that the Unity mergetool is wonky at best, and checking that all of those changes merged properly would take longer and be more error prone than simply copying one persons work over the other.

We resorted to simply asking in chat if anyone has any uncommited work, but with SVN (or any other centralized VSC, I suppose) we wouldn't have to bother with that - you simply lock the scene file and be safe.

Because we always used it!