[yellowapple]

I think we're gonna have to agree to disagree on that. I've found that locking a file from any changes entirely almost always causes more problems than it ostensibly solves, and is a massive impediment to productivity on any team larger than a single person. The vast majority of the time it's entirely unnecessary anyway.

[domlebo70]

Absolutely agree with you when it comes to textual/structural information where merge conflicts can be solved easily. But for binary like formats, I feel often there is no way to resolve a conflict.

[joshuamorton]

Yes, but you probably don't make a habit of storing music or video (or weird proprietary binary animation formats) that people are modifying in git.

[yellowapple]

Indeed I do not. If game developers (and/or game engine developers; looking at you, Unity3D...) showed similar restraint, then they likely wouldn't feel the need to tie themselves to 90's-esque version control schemes.

[pnako]

The game industry has a completely different way of working compared to other tech fields. Most of their practices seem old fashioned, or anti-patterns, etc. if you look at them from an outside point of view.

But they're trying to do something very hard: control both quality and deadline. It's not like an open source or enterprise IT project. The game has to be finished, good, by a given date. To do that they do many things, including slaughtering sacred cows about how things are supposed to be done. If hard locking saves them time by avoiding wasted efforts, by artists who are probably over-worked already, then what's the problem?

[yellowapple]

> But they're trying to do something very hard: control both quality and deadline.

Do you believe other tech fields are not trying to do the same exact thing? Do you believe that enterprise IT projects are somehow less beholden to both quality and deadlines than video games?

Controlling both quality and deadlines is what literally every (professional) software development project should be doing. The implication that game developers are somehow better about or more cognizant of this (let alone specifically because of broken development workflows) is pretty rich considering how frequently big-budget video games end up in development hell (see also: Duke Nukem Forever) and/or end up riddled with bugs (see also: literally everything Bethesda's released in the last decade or so).

(Not saying that enterprise IT is necessarily better in either regard, of course; bugs and delays are inevitable as software complexity grows, be it an RPG or an ERP...)

> If hard locking saves them time

It doesn't save time in aggregate, though. It maybe saves time for one specific corner case (conflicting edits on binary files) at the expense of slowing down everything else.

And if you're at the point where "conflicting edits on binary files" is no longer a corner case, then that betrays at least one of two dysfunctions:

- You're using some sort of container format instead of sanely keeping things split into separate texture/model/animation/normal/behavior/etc. files (and then - if the amalgamated container file is indeed necessary - combining it as part of the build process). If you're really running into a lot of cases where multiple people are trying to edit the exact same normal map at the exact same time, then...

- You've got a communications breakdown somewhere. You can band-aid over that with file locking, but that still doesn't address the issue of two people trying to independently edit something in the first place.

[cweagans]

You're not really going to get away from large binary files in game development. They need to be version controlled somehow. Adding more layers of indirection for how that actually happens is just kicking merge vs file locking can down the road.

[pmjordan]

Additionally, you have artists and level designers working on these files. These people tend to be semi-technical, and confronting them with the full details of git is usually met with a lot of resistance.

I know some smaller studios that use git to some extent, and they tend to struggle with it on occasion - again, primarily in the art & design departments, mainly with binary files. All the larger studios and some of the smaller ones seem to use perforce. Publisher-owned multinationals might have their own proprietary systems, I don’t have any insider information there.

In any case, people who aren’t familiar with the requirements of gamedev like to argue about this. It’s like proponents of forks arguing with someone trying to eat soup with a spoon.

[yellowapple]

> You're not really going to get away from large binary files in game development. They need to be version controlled somehow.

Yes, but if they really can't be split up into smaller components, then there's always the option of using a different repository and VCS specifically for binary assets. Yes, it's kicking the can down the road, but at least it's kicking that can away from the actual code.