A lot of game studios use Perforce (p4) - while it's not distributed, it seems to be easier to non-programming folks - artists, producers, etc.

And git can still be used along with it - For some of the lib/tools that I do, I create a ".git" repository living along with p4, and work like this - then submit in P4.

Also, "exclusive checkout" is something that doesn't even really make much sense in git, but is important for people collaborating on non-mergeable assets (3D models, textures, etc). We end up using git for code and in-game assets but p4 for source art assets.

Some small game studios also don't use git. Famous indie developer Jonathan Blow[1] said they had 20GB of data on a svn repo 6 months ago: https://news.ycombinator.com/item?id=6745412#up_6746172

[1] Braid here if you haven't: https://www.youtube.com/watch?v=uqtSKkyJgFM

Perforce also handles large binary blobs better as well, which is super important in game programming.

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.

How is git with a gui hard for artists? I get that they don't want to stage their changes and commit them from a terminal, but you literally just pick your files and write a note about what you did before hitting the commit button.

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-...

FWIW, git will never store two copies of the exact same file in the same repository, since the blobs will have the same SHA-1 hash.

Right. But when you change one thing in the the PSD git can't do a diff and store the diff. Which means you now have basically the same 500meg file duplicated.

SVN and the like will attempt to store the binary deltas instead of duplicating the files. I don't believe git can actually do this due to the way branches / git itself works (it doesn't have a simple #1 - #2 - #3 ... #n commit chain setup)

There are plugins for handling binary assets better but they aren't great. and/or it just makes it less intuitive for the non-programmers which really defeats the whole purpose.

I absolutely _love_ git and I'm 99% sure this issue will be worked out at some point. I've seen teams just use git for the code and then use something else for art assets (alien brains or something).

Git packs are mostly made up of deltas. Git is remarkably efficient at diffing files. And because it's all handled at the the storage level it doesn't matter what order the files are in, it generally packs all the revisions of a file from largest to smallest with the a compression window several versions wide. The problem is that it's still a lot of data when you have significant binary assets.

Edit: The default is to delta files up to half a gigabyte in size.

Sure, but that rarely matters here, as artists are working on the assets.

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?

At what point would Vim appear when using a gui client for git?

the github client is actually extremely artist friendly.

Not much commercial game development goes on on github, which IIRC is the only way to use the github client. (Where I work we have a local gitlab.)

Since commercial developers on github presumably use private repositories, how would you tell?

You can use the github client with non-github repos as well.

But not particularly stable. At least when I tried to use it about a year ago

As is sourcetree, and not tied to github

Plastic SCM is targeting Perforce users who want to go to a distributed model.

I really hope you're being sarcastic. If you're turning a job down because of the VCS, hopefully you've got a surplus of work to choose from.

I understand the sentiment: the fact that a company uses Visual Sourcesafe, or ClearCase, or something else terrible tells you a lot about their culture.

I'd be inclined to agree with you in some cases ("any port in a storm"), but otherwise I would view a VSS or ClearCase shop as one that's possibly on the wrong side of the technology curve. I have worked with VSS, p4, cvs, svn, hg, and git (and arms length with evil things like ClearCase and more primitive stuff like RCS). Everyone should have an idea of the minimal toolchain they want to work with.

But that aside.. massive props to the Git team on 2.0!

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.

engineers do in the bay area.

and in seattle

I can almost understand with something like Subversion (which seems to subtly skew the entire development process to work around the friction some of its basic operations introduce), but not even Mercurial? :(

Not even Mercurial :) Haha j/k I actually don't mind Mercurial, but I'd still rather work with git.

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

Nope. Mercurial devs rebase heavily during Mercurial development, for instance. It's Changeset Evolution [1] that makes history rewriting _safe_.

[1]: http://mercurial.selenic.com/wiki/ChangesetEvolution

I've been using git-svn for workflow the past 2 years or so. It's not perfect, but it seems to cover all the use cases I've had and integrates well with the regular svn workflow.

> I probably wouldn't even take a job if they were using one of the other DVCSs.

Why? At my current workplace, I converted a svn repository (with 6 years of commits) to git without any hiccups! I did not even lost a single commit!

I also detached a huge binary directory (they committed everything to svn...) and made a different repo for it.

Also you got git-svn, with you can seamlessly commit to an svn repo and still work in git on your local machine, nobody will notice, except you!