Where I work (game company with about 20 people) we solve this by versioning unimported assets separately (in svn, because that's what we used before git).

We bring them into the git repo after running them through our asset pipeline, which means that there are really never any merge conflicts for them and every checkout is a playable version of the game with art.

This reduces the load on git by a lot, though we still tend to have .git folders measured in the tens of gigabytes, which is getting up there.

It's not the GUI that's the problem. The difficulty comes when you pull/fetch-merge and somebody has pushed a change in a file you're editing. Binary files aren't easy to merge, so now you're going to lose your changes, or they're going to lose theirs. This is the problem the check in/check out (lock/unlock, whatever) mechanism is designed to solve. It gets in your way a bit when working on files that could be automatically merged, but it's completely necessary when working on files that can't.

A system like perforce stores the files read-only on disk, and makes them writeable when you check them out. To do that you visit the perforce GUI and try to check the file out; if somebody else has the file checked out already, the server will tell you who it is, so you can go and talk to them and decide how you're going to order the edits.

(Because of the read-only flag, even if you don't check out at least the files you know you'll need before you start work (which you should do), you at least find out immediately when you try to save. So even if you then end up losing a bit of work - it happens - you at least won't get too far into your work before finding this out.)

I think the bigger point is that game studios check in assets. And you don't want the complete history of game assets over 2 years of development and iteration on your machine. And git is generally not optimized for huge binary files.

git does have very very bad binary asset management. It doesn't really work like svn/perforce in a logical tree structure and each commit has it's own hash and isn't necessarily ordered so there ends up being a _lot_ of copies of binary assets (git -unconfigured- will attempt to store deltas between changes but it can't do that with binary assets... and over time gets _very_ slow with large binary assets).

This isn't necessarily horrid for web apps as the images aren't big. But when you're talking about 500mb PSD files and massive massive 3d maya/max scenes it's horrid.

http://stackoverflow.com/questions/3055506/git-is-very-very-...

Having used both extensively, Perforce workflow is just a lot easier for a layperson to understand. Add files to changelist, move files between changelists, remove file from changelist, check it in. It has a nice GUI and command line tools. With git you have staged files vs commited files, commit vs push, multiple commits and the need to rebase, difficulty of removing a file from the commit before push, not to mention lack of a good built in visual merge solution tool and stuff like detached head state. Git also has a more complex command line, and multiple UI choices, none of which are great. I love git and it is my vcs of choice, but just because we know, love, and understand it doesn't mean intern Katie from the art team is going to feel the same way.

I think perforce deals with binary files better too (not sure of the details)

And what when, suddenly, vim appears and they have no idea of why or how to close it?

First month at the previous gig was spent writing an SVN-based implementation of SCCS because their workflow required SCCS locking etc. and they wanted to move the backend to SVN for the eventual "moving the developers to not all working in the same directory" project.

It was a very tearful month.

and in seattle

They're essentially identical. Mercurial just has slightly easier to understand syntax and and a cultural bias against rebasing.