Perforce

Posted Oct 22, 2009 7:38 UTC (Thu) by cmccabe (guest, #60281)
In reply to: Perforce by SLi
Parent article: KS2009: How Google uses Linux

> What on earth makes people (or companies) use Perforce?

I've worked with perforce, subversion, and git in the past. The three systems all have very different philosophies.

perforce has some abilities that none of the other systems have. When you start editing a file, it tells you who else has it open. You can look at their changes, too.

Both perforce and subversion can check out part of a repository without checking out the whole thing. Git can't do this. Arguably, you should use git subprojects to solve this problem. I've never actually done that, so I don't know how well it works.

Of course, git allows you to work offline, which neither perforce nor subversion can do. git also allows you to merge changes from one client to another ("branch," in git lingo). I've definitely been frustrated in the past by having to manually port changes from one perforce client to another-- even wrote scripts to automate it. What a waste.

"p4 merge" is a powerful command, much more powerful than "svn copy." p4 preserves the "x was integrated into y" relationships between files, whereas svn does not. Imagine a company that has branches for product 1.0, 2.0, and 3.0. It periodically integrates changes from 1.0 into 2.0, and 2.0 into 3.0. In this situation, the relative lack of sophistication of svn copy is a real Achilles heel. Imagine how much pain renaming a file in version 2.0 causes for the hapless svn copy user. Each time the build monkey does the integration from 1.0 to 2.0, he has to remember the files that were renamed. Except that with perforce, the system remembers it for him.

git I think has heuristics to detect this sort of thing. In general git was built from the ground up to do merging on a massive basis.

perforce also has excellent Windows support, a pile of GUI tools, and was about a dozen years earlier to the party. git and svn are catching up with these advantages, but it will take some time.

Perforce

Posted Oct 22, 2009 19:17 UTC (Thu) by dsas (guest, #58356) [Link] (1 responses)

Subversion 1.5 has merge support, it's not as good as say bzr or git but it's better than svn copy.

Perforce

Posted Oct 30, 2009 21:57 UTC (Fri) by lkundrak (subscriber, #43452) [Link]

Our company's just moving away from subversion, though it serviced us well for some time. As the project grows, the svn merge support is really "worse than nothing." With a development team of ~30 engineers, I am constantly seeing issues like unable to merge after moving a file with a mergeinfo property from subtree merge, wasting considerable time on fixing up mergeinfos after engineers branch off other branches and do cross-branch merges. Moreover, the merge mechanism is different in 1.4, 1.5 and 1.6. Cryptic error messages tends to scare people off a bit too. Squashing all the commits of merge source into one commit in target greatly devaluates certain tools, such as annotate too; which was not an issue when the project was smaller, but gets rather annoying with the history growing.

Perforce

Posted Oct 29, 2009 3:05 UTC (Thu) by tutufan (guest, #60063) [Link]

> When you start editing a file, it tells you who else has it open.

Wow. I can almost hear the punch card reader in the background. Talk about an obsolete mindset. If I'm editing file X, do I really want to know whether somebody, somewhere, working on some idea that I have no idea about, is trying out something that also somehow involves file X, something that ultimately may never see the light of day? No.

If we get to the point of merging, I think about it then (if necessary).