Steve’s analysis is dead-on. Worth reading if you’re looking into replacing p4 with git (as I am).
Most of the discussion in the comments is from people unfamiliar with what it’s like to work on a large project with lots of content. Lots of uninformed comments like “source control is for source code”. I think what they mean is “git is for source code”, which is what Steve has obviously concluded.
Now, I’ve been hearing such great things about git, and so I’ve been trying to figure out how I can integrate it into part of our process to give it a real try, maybe towards eventually replacing Perforce. Perforce is really expensive, and their development seems to be standing still in comparison with other systems like git and mercurial.
But git seems to suffer from the same problem as all open source SCM’s: it totally dies on large binaries, or when you have a billion files. Things that Perforce does without an issue. Not to mention all the GUI apps to manage it currently suck. I would be terrified of asking an artist to use any of them.
Still, I am dying to get some of that sweet git functionality. The Perforce people don’t seem to be working on anything like staging areas, stashes, or the ‘push’ feature. Their server hasn’t moved far in the last 10 years that I’ve been using P4.
So I’m going to try building git-like features on top of p4api.net. We already have a suite of tools for this, though most are for server features such as submit triggers, automatic checkpoints, managing clients, or emailing change reviews. Only a couple on the client side so far (like an automatic Crucible code review builder).
Maybe it’s time to start extending that tool to build some clones of git client-side tools. Should definitely be possible, using a special private area in the depot for storing state.