Earlier quoted context omitted.
Merge conflicts are definitely not the same thing as file locking. At the point where you're getting a merge conflict, it's too late. How are you going to resolve conflicts in an audio file? File locking is a way to communicate in advance that nobody should attempt to make changes to a particular file until the lock is cleared. Merge conflicts are communication in arrears (so to speak) and at that point, effort has a…
> How are you going to resolve conflicts in an audio file? By choosing one and discarding the other, or by creating a new audio file that incorporates both changes, just like one would do for any other file. While I don't know if this exists, there's nothing theoretically preventing the creation of a diffing/patching tool for audio/video files, detecting insertions/deletions/replacements (perhaps by timestamp/frame r…
Locking the file is a signal not to work on it because someone else is modifying it. There isn't currently software that supports semantic merging of audio or video, so perforce says "someone is recoloring the asset, don't change the animation until they're done, or you'll just have to do the work again".
In the meantime, perforce prevents you from checking the file out. So you have to explicitly and clearly bypass your source control to do what you suggest, at which point someone rightfully yells at you.