5 ms·

"I used to hear people say good things about Perforce, but now the feeling seems to be that it doesn't have compelling advantages over Subversion, let alone the

"I used to hear people say good things about Perforce, but now the feeling seems to be that it doesn't have compelling advantages over Subversion, let alone the DVCSs." Perforce still has better support for branches than Subversion does - in particular, it has robust support for repeated merges between branches. Subversion 1.5 added "merge tracking" which is supposed to address this problem, but in my real-world use Subversion still failed relatively often at repeated merges and the recovery process is tedious and annoying. On that particular project we ended up switching to git, but I would definitely choose p4 over svn for use cases (like very very large repositories) where they are both better than git or hg.

btilly 17y ago
The biggest advantage that Perforce has is better performance with large code bases than subversion, git, or mercurial. My guess is that most of us don't work with large and active enough code bases for this to matter. But if you do, consider Perforce.
- snprbob86 17y ago
  As someone who has worked on several large code bases with Perforce, Source Depot (Microsoft's Perforce fork) and TFS (Microsoft's Perforce rewrite/productization), I honestly think that the ability to handle really large code bases is actually more of a curse than anything else. See my old post about version control scaling up vs scaling out here: http://news.ycombinator.com/item?id=659251 http://news.ycombinator.com/item?id=659251
- yason 17y ago
  These said large code bases are usually much less of code and much more of binaries, test images or media streams, complete devtool suites, arch compilers, and almost anything that generally would require less version control and more availability control. In other words, stuff you would actually want to live on a network drive or some other sharing mechanism. But if it's easy enough to shove 10 gigabytes to Perforce, it will happen.
  - InclinedPlane 17y ago
    For some of these things, sure. But if you put your compiler tools, external binary references, etc. on some share somewhere outside of version control you will find that when you go to create a patch for some older release you are well and truly effed. Being able to sync and build with nothing but a bare OS and the relevant source is a HUGE benefit when you have to support older releases on the level that, say, Microsoft does.
    - yason 17y ago
      It is still the wrong solution. Disk space is cheap and what you really want is access to cumulated, unchanged old versions -- not version control: you generally don't diff or merge between compilers or test images. Instead, you can store builds of each and every gcc version you've ever used on a network disk with very little money and then properly use the version control system to have the different revisions of the source code point to the correct set of tools and resources. It's like a persistent data storage with good accessibility and no delete command. This is the only real reason why people abuse their version control system with huge binaries and it's the only reason I can think of. I shall bow to anyone who has the guts to refuse to abuse and do it properly instead.
stephen 17y ago
Given the known bugs [1] that reflect your svn merging experience, it seems the majority of svn users, myself admittedly included, just never do reflective merging in svn or else there would be more of a fuss over it. As a good illustration for others of what you're talking about, the bug report points to this picture [2] in which commit 17 to trunk is what causes svn problems. [1]: http://subversion.tigris.org/issues/show_bug.cgi?id=2897 http://subversion.tigris.org/issues/show_bug.cgi?id=2897 [2]: http://www.open.collab.net/branding/images/projects/merge/repo.png http://www.open.collab.net/branding/images/projects/merge/re...
jrockway 17y ago
Other than that, Perforce is junk. Here's a nice feature. To decide what files to commit, you edit the boilerplate "p4 submit" generates in $EDITOR. Except if there is a problem exec-ing $EDITOR, p4 just decides to commit all your changes with no message. p4 may be good server-side, but the clients are junk, and I wouldn't trust them with anything important. Like with Subversion, if I ever have to do something complicated, I always make a "cp -a" backup first. Git may be "hard to use", but at least it doesn't shred my work for no reason.

btilly 17y ago

The biggest advantage that Perforce has is better performance with large code bases than subversion, git, or mercurial. My guess is that most of us don't work with large and active enough code bases for this to matter. But if you do, consider Perforce.

snprbob86 17y ago
As someone who has worked on several large code bases with Perforce, Source Depot (Microsoft's Perforce fork) and TFS (Microsoft's Perforce rewrite/productization), I honestly think that the ability to handle really large code bases is actually more of a curse than anything else. See my old post about version control scaling up vs scaling out here: http://news.ycombinator.com/item?id=659251 http://news.ycombinator.com/item?id=659251
yason 17y ago
These said large code bases are usually much less of code and much more of binaries, test images or media streams, complete devtool suites, arch compilers, and almost anything that generally would require less version control and more availability control. In other words, stuff you would actually want to live on a network drive or some other sharing mechanism. But if it's easy enough to shove 10 gigabytes to Perforce, it will happen.
- InclinedPlane 17y ago
  For some of these things, sure. But if you put your compiler tools, external binary references, etc. on some share somewhere outside of version control you will find that when you go to create a patch for some older release you are well and truly effed. Being able to sync and build with nothing but a bare OS and the relevant source is a HUGE benefit when you have to support older releases on the level that, say, Microsoft does.
  - yason 17y ago
    It is still the wrong solution. Disk space is cheap and what you really want is access to cumulated, unchanged old versions -- not version control: you generally don't diff or merge between compilers or test images. Instead, you can store builds of each and every gcc version you've ever used on a network disk with very little money and then properly use the version control system to have the different revisions of the source code point to the correct set of tools and resources. It's like a persistent data storage with good accessibility and no delete command. This is the only real reason why people abuse their version control system with huge binaries and it's the only reason I can think of. I shall bow to anyone who has the guts to refuse to abuse and do it properly instead.

stephen 17y ago

Given the known bugs [1] that reflect your svn merging experience, it seems the majority of svn users, myself admittedly included, just never do reflective merging in svn or else there would be more of a fuss over it. As a good illustration for others of what you're talking about, the bug report points to this picture [2] in which commit 17 to trunk is what causes svn problems. [1]: http://subversion.tigris.org/issues/show_bug.cgi?id=2897 http://subversion.tigris.org/issues/show_bug.cgi?id=2897 [2]: http://www.open.collab.net/branding/images/projects/merge/repo.png http://www.open.collab.net/branding/images/projects/merge/re...

jrockway 17y ago

Other than that, Perforce is junk. Here's a nice feature. To decide what files to commit, you edit the boilerplate "p4 submit" generates in $EDITOR. Except if there is a problem exec-ing $EDITOR, p4 just decides to commit all your changes with no message. p4 may be good server-side, but the clients are junk, and I wouldn't trust them with anything important. Like with Subversion, if I ever have to do something complicated, I always make a "cp -a" backup first. Git may be "hard to use", but at least it doesn't shred my work for no reason.