We believe source control should be everywhere and git isn't great yet to work with large binaries. Git(Lab) Annex makes things much better for people working with these kinds of repositories.
As I mentioned in another thread, efficient storage of these files is necessary, but not sufficient. Exclusive locking is a requirement for working with editable (but not mergeable) binary files in a team environment. It's the reason most games studios use Perforce or SVN instead of git. Tracking locks using a separate system does not scale, it needs to be integrated and enforced by the VCS.
PlasticSCM has a hybrid approach that is worth studying.
Locking is indeed nice to have. We're considering adding locking to the web interface of GitLab. But we'll probably wait for a customer to sponsor this.
Woukd you mind explaining a bit more why locking is a requirement? It sounds more like an organisational issue rather than something required in SCM.
Taking the game studio example, why would two developers/artists/whatever need to work on the same asset at the same time? Locking stops them from stepping on each other's toes, but it also means one has to wait for the other to finish their task before they can do anything.
Stepping in each other's toes is part of the game artist workflow. :)
Seriously, with the tens of thousands of assets in a medium to large game, the way they can be reused across the game, and the peculiarities of art and in-house tools, it's not uncommon for two artists to try to modify the same asset. Sometimes it's accidental, sometimes it's necessary, sometimes it is an oversight, sometimes it is an organisational issue as you say... but locking detects the conflict and prevents it from turning into wasted hours or days.
Relying on a separate tool to manage this issue is a notable increase in friction. Since the SCM handles changes and conflicts for source code (and thankfully allows merging), why wouldn't it do so for art?
We'd love to get feedback on it.