5 ms·

How does this compare with magit? Also are there places where Preforce is still better than git/hg?

maximilianburke 11y ago
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.
- tenfingers 11y ago
  Is 'looooooooooove' ironic? I've used p4 for several years, and even though I now basically only use git, I still think it's one of the best thought-of and implemented SCM systems out there [disclaimer: never used bitkeeper]. It's simple, elegant, compact and well performing in any scenario. You don't need a "perforce from the group up" tutorial to understand how it works. p4v is awesome for history navigation: no git frontent comes even close. Shallow repositories somehow mitigate git issues for large repositories, even though it isn't convenient. Over time I came to appreciate some advanced manipulation commands in git so I don't think I'll ever switch back, but I hope Perforce will continue to go strong, as it's a very solid product.
  - yo-code-sucks 11y ago
    Yeah, fuck simplicity, let's clobber and merge every fucking thing.
  - maximilianburke 11y ago
    No, not ironic or sarcastic at all! It really is wonderful. We're starting to scale up our edge/commit server network in order to have teams iterate on 100+GB repositories across five+ locations in North America and Europe and it mostly just works.
gleb 11y ago
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.
tutufan 11y ago
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.

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.

tenfingers 11y ago
Is 'looooooooooove' ironic? I've used p4 for several years, and even though I now basically only use git, I still think it's one of the best thought-of and implemented SCM systems out there [disclaimer: never used bitkeeper]. It's simple, elegant, compact and well performing in any scenario. You don't need a "perforce from the group up" tutorial to understand how it works. p4v is awesome for history navigation: no git frontent comes even close. Shallow repositories somehow mitigate git issues for large repositories, even though it isn't convenient. Over time I came to appreciate some advanced manipulation commands in git so I don't think I'll ever switch back, but I hope Perforce will continue to go strong, as it's a very solid product.
- yo-code-sucks 11y ago
  Yeah, fuck simplicity, let's clobber and merge every fucking thing.
- maximilianburke 11y ago
  No, not ironic or sarcastic at all! It really is wonderful. We're starting to scale up our edge/commit server network in order to have teams iterate on 100+GB repositories across five+ locations in North America and Europe and it mostly just works.

gleb 11y ago

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.

tutufan 11y ago

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.