More generally, though, this sounds like the sort of thing that should be prevented by policy and backed by tooling and/or code-reviews if you have a good reason to be checking binaries in. The problem doesn't sound like the lack of protections, but of carelessness or build processes that change/produce binary artifacts willy-nilly.

(This is in the context of non-programmers using source control for assets etc) I argue that the 'P4 lock' is less protection and more process. I can't remember if SVN did this but P4 would tell who locked the file and ensures that you have the latest version before locking and therefore becomes part of the process of working with non-mergable assets.

Yes, I'm finding it is common for people to want concurrent access to unmergeable files. Different designers sometimes want to tinker with different rows in a spreadsheet, or different parts of a design doc. Level designers or environment artists might be tweaking different parts of a map, or editing different values on a complex prefab.

It seems to me that talking about better practices is a coder-centred view of things. If 2 coders both work on the same file, we assume version control will handle it safely in most cases. But if 2 designers or artists both work on the same file, we suggest that they're the ones at fault, mostly just because the technology doesn't handle their files as well as it handles ours. If diff/merge didn't exist and we had to replace our files wholesale, I think coders would be less dogmatic about this.

Don't get me wrong - I hate Perforce with a fiery passion, and would choose Mercurial or Git whenever asked. But there will come a time when your artists or designers are angry because their hard work is being overwritten by someone else's hard work and they can't just merge and rebuild like we can.

When I label it a process smell I'm not limiting myself to source control processes -- that's just the tooling we're employing here to work around what's ultimately a tools/formats deficiency: The inability to merge the work in the first place. I'm glad we programmers (and other text-jockeys) have the privilege of very good merge tools, and if others had the same benefit we could all live happily ever after -- Locks don't address the actual problem, they just prevent it by forcing serialization; source-control process too, for the most part, without the ability to merge that work. We fundamentally can't scale up as long as we're stuck serializing the workload.

We should be striving for mergable file formats so that the bulk of changes can be merged automatically, and having that we could view two designers or artists making mutually-exclusive changes for what it really is: a break down in communication. The reality that locking a file in your version control addresses is that certain file formats make the file the smallest unit of granularity that can be reasoned about. Locks might be a necessary, if convenient, evil for the time being and we probably can't make everything lock-free, but they're no less a smell in your version control system than they are in your concurrency-seeking code.

Its not a trivial problem though, that's for sure. Heck, there's not even a good merge tool for XML as far as I'm aware -- indeed the format spec itself makes developing such a tool basically impossible.

There's also no need to keep your design documents in the same repository as your source code.
Code repos need to be able to solve problems like, retrieving the exact state of the project as to bit for bit reproduce the build that was submitted last summer so that a bug can be tested and a hotbox created.
In doing this kind of work, you don't also need to retrieve the state of the designer's thoughts on the games direction from last summer too.

In my experience it's quite common to use more than one source control tool, as well as more than one repository.