[yellowapple]

> 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 rather than by line) the same way `diff` does for text.

> at that point, effort has already been wasted by at least one person.

A file lock doesn't prevent that time waste; there's nothing stopping someone from immediately overwriting it as soon as the first editor commits/releases the lock (in which case the first edit was a complete waste of time).

[joshuamorton]

I don't quite think you understand how perforce works.

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.

[yellowapple]

> Locking the file is a signal not to work on it because someone else is modifying it

I know how file locking works. Like I've said before, my day job involves using a locking-based version control system. My disdain for locking-based version control comes specifically from having to put up with it instead of using something sane like Git.

> So you have to explicitly and clearly bypass your source control to do what you suggest, at which point someone rightfully yells at you.

And yet that will inevitably happen anyway, because someone's breathing down your neck to get that animation done and won't take "well I'm waiting for Bob to finish recoloring first" as an answer. Cue the aforementioned fistfight over whether Alice's animation or Bob's recoloring can happen first.

Or it'll inevitably happen due to the aforementioned risk of deadlock (Alice is tweaking animations in a different order than Bob is tweaking textures, and thus run into a situation where both are waiting on the other to release locks on files; cue fistfight).

I've seen both cases happen repeatedly. All of those cases would've been avoided had we used a version control system that used branches and merges instead of locks and unlocks.

[cweagans]

> because someone's breathing down your neck to get that animation done and won't take "well I'm waiting for Bob to finish recoloring first" as an answer

As it happens, that's exactly the answer you're supposed to give. It's not like game devs have any shortage of things to work on at any particular time.

> All of those cases would've been avoided had we used a version control system that used branches and merges instead of locks and unlocks.

I don't think you're thinking this through all the way. If I have 5 different branches where textureA.png got modified, which one is the right one to end up with after everything is merged? Who is going to have to re-do work? Branches do not solve that problem, and without out of band communication, that problem is made significantly worse than if those changes were done in sequence (which is what file locking enforces).

[joshuamorton]

> I've seen both cases happen repeatedly. All of those cases would've been avoided had we used a version control system that used branches and merges instead of locks and unlocks.

Well no, the failure modes would be different, but all of those things would still cause problems with branching and merging, mostly because you can't actually merge binary artifacts, only rebase.

And in a world where you can only rebase, locking actually makes sense.

[yellowapple]

> all of those things would still cause problems with branching and merging

The deadlock most certainly would not. One would get rebased on top of the other, in the worst case.

(In the best case, Alice and Bob would both be committing/pushing to their respective branches early and often, and could therefore look at each others' branches and see what changed between them; if you really want to emulate locking, you could do so pretty straightforwardly by checking if there are any changes to that file in commits outside of your own branch's commit history, and it should be doable to write automated tooling to that effect. All the "benefits" of locking without getting in the way of anything.)

> And in a world where you can only rebase, locking actually makes sense.

Even in a world where you can only rebase, locking is far more of a hindrance than a benefit, for the reasons already outlined.

[wizzwizz4]

A lock prevents you from opening it to edit in the first place, without warnings that "so and so user is currently editing this, are you sure you want to open this as read-only?". This reduces accidental time waste (and computer systems shouldn't try to protect people from deliberately wasting their own time, because they probably aren't).