New Fun Blog – Scott Bilas

Take what you want, and leave the rest (just like your salad bar).

Perforce vs. git

with 6 comments

My friend Joel pointed me at a great posting by Steve Hanov about the scalability problem of git vs. Perforce.

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

Oh look! There’s a ‘p4tar‘ tool in the public depot that I can start with in implementing a clone of git’s stash!

April 24th, 2009 at 12:38 pm

Posted in git,p4

6 Responses to 'Perforce vs. git'

Subscribe to comments with RSS or TrackBack to 'Perforce vs. git'.

  1. C’mon, just write a nice clean P4 client instead. P4Win morphs to P4.Net. For serious, P4V make my (and my artist’s) eyeballs bleed.

    Sigh. Remember when you used to be able to unequivocally answer “SCM?” with “Perforce”?

    Jonathan Grant

    24 Apr 09 at 1:21 pm

  2. […] I mentioned in a previous post, this is one of the top features from git that was making me seriously consider checking it out. I […]

  3. What’s the large binary use case? Why would you version binaries using a source code versioning system?


    30 Apr 10 at 3:01 am

  4. This is a common response to the “subversion sucks for binaries” problem. The issue is that it’s not about source code versioning (which is what I’d call an “argument from definitions”), it’s about revision control. And revision control systems that are limited for technological reasons to text files are just impractical for anyone doing large scale integrated code and content production. This is why nearly all big game studios use Perforce and not Subversion or git or any of the others that assume text only. They fall over hard with binaries.

    Game studios typically put tens of gigs of data into revision control. Binary or text does not matter. What matters is that we get atomic checkins of changelists, full history, rollback ability, broad distribution to the entire team, high speed, and so on. Saying “it’s for text only” is taking a narrow view.


    2 May 10 at 2:08 pm

  5. Git is fine with a ton of files, more than perforce at times.

    Git is not fine with large binaries.

    You can set up git to .gitignore your large binaries. You can stash you binaries in subprojects. You might not think this effort is worth it. They can be handled, but perforce still might be the tool you want to use.

    Personally I’ve seen perforce trash my data more than once, so I think the larger-effort tradeoff is worth it.

    Joshua Rodman

    27 May 10 at 1:43 pm

  6. “Stash your binaries in subprojects” means what exactly..? If it means splitting our revision control needs into two completely separate systems and workflows, then that’s a deal breaker. The last thing we’d need is to double our tool, test, and training surface area.

    Strange that you’ve seen P4 “trash” your data. Given their reach and the large scale installations they have, the first place I’d look on any claim of corruption is user error or server config.


    28 May 10 at 7:00 pm

Leave a Reply