Emacs/Perforce integration: a retrospective

We loooooooooove Perforce in the games industry because it handles repositories with hundreds of gigabytes of binary data better than most (if not all) other source control systems. It's fast, reliable, and space efficient on the client.

The DVCS features in the new versions of Perforce plug the holes where a lighter weight solution is desired, and have also been allowing us to more seamlessly mirror projects across previously separate servers.

magit and p4.el are different. The scope of the projects is different - p4.el is a thin wrapper over p4, magit is an full blow UI both exposing and going beyond the underlying git's "porcelain".

Compared to git Perforce command line interface is much smaller and more consistent. And it is designed to be invoked from an editor/IDE. This makes p4.el job easier than magit's. p4.el has fewer features, needing less code, and can reuse more of this code.

p4.el UI was also designed to mirror p4's interface using the same commands and vocabulary. This makes it unusual in Emacs world where SCM interfaces tend to use UI derived from to pcl-cvs. p4.el does not. magit clearly started out similar, but is now vastly more ambitious, but still has some of this flavor.

W.r.t. editor support - for any command where the CLI would open P4EDITOR with some template filled in (like say committing) - p4 has an equivalent workflow which can be easily automated from within an IDE. I.e. it has one command/option that will spit out the template, and another command/option that will accept this template filled in, from stdin. It's hard to believe but git lacks this feature. So, magit has an elaborate library to work around this using emacsclient.

No. Perforce is basically the combined worst of Subversion and Visual Source Safe, and something you wouldn't wish on your worst enemy.

Because it is so limited, it happens that you can store huge BLOBs in it, which is something that's not directly possible with git (but see git-annex). This isn't really a limitation, though, because the desire to store huge BLOBs in your version control system alongside C++/etc source is utterly confused. For large, undiffable assets like that, you want to keep them in a permanent store, kind of like the way the gnu.org keeps the tarballs for its multitude of projects.

There's a reason why absolutely nobody uses Perforce for personal projects, even though the license to do so is free. It's because Perforce's day, if it ever had one, is long gone. It's just an attractive nuisance now.