I've heard that Perforce is very good at merging, I'm guessing this has to do with that it tracks changes in the form of changelists where you can add differences across several files in a single blow. I think this implies Perforce gathers more metadata and therefore has more information to do smarter merging (at least smarter than Subversion, being Perforce centralized).

Since this is similar to how Mercurial and Git handle changes (I know DVCSs track content rather than files), I was wondering if somebody knew what were the subtle differences that makes Perforce better or worse than a DVCS like Mercurial or Git.

  • 1
    I must say my experiences (regarding Perforce being good at merging) are the opposite. I saw Perforce completely screw up complex merges several times, while have had less trouble with Subversion. Of course, the experiences come from totally different projects so they aren't directly comparable. This is just my subjective memory. Oct 12, 2012 at 7:31
  • 2
    I've had precisely the opposite experience to @PéterTörök. For me, Subversion merging has screwed up several times, but Perforce has not missed a beat. I suspect that (for both of us) it is more to do with the driver than the driven. :-) Having said that, I believe (subjectively) that git's merging is superior again.
    – Peter K.
    Oct 12, 2012 at 11:45
  • yeah, i kind of look in awe at those people who used svn and still had positive things to say about it. even the folks that designed svn admit its data model is inferior.
    – kayaker243
    Oct 12, 2012 at 19:01

2 Answers 2


Very good, especially given perforce's competition (cvs, svn, etc) over most of its life, but no, not as good as Git. I can't speak to hg.

While some of this is off-base (the p4 shelf is now an old feature, no, you can't make a dvcs behave just like a vcs, and it seems silly to knock p4 for xcode dropping support) the choice bits about p4 merging headaches are accurate.

I don't think there's anything inherent to a distributed version control system that makes its merging naturally superior to a centralized system like perforce. Rather, the data models adopted by many dvcs's lend themselves to superior branch and merge tracking.

Perforce branch mappings? A cumbersome alternative to git's pointers and directed graph approach.

One key advantage of git over perforce -- tracking code through refactoring -- has nothing to do with git's status as a distributed version control, but rather the fact that it looks at both files and blobs of content as first class citizens in its data model. This is completely different from perforce, which keeps extensive metadata in its database on a file-by-file level: file state, history, attributes, changelists, while versioned file content is stored separately in a filesystem hierarchy.

Lastly, and this may be a bit unfair but I feel that if a version control system needs to have a file locking feature, it probably doesn't bode well for its branching and merging sophistication.

For a biased comparison of git vs. perforce (archived link). I also find it telling that perforce has itself jumped on the gitwagon.

  • 1
    For those that are interested, this answer on SO has a bit of additional info around the DVCS data models and why they typically facilitate better merging (SVN vs. git used in the example).
    – Daniel B
    Oct 12, 2012 at 6:35
  • wow wow wow, that answer blows mine out of the water. thanks!
    – kayaker243
    Oct 12, 2012 at 18:59

It depends on how you use Perforce. I seen the 'everyone has a branch' approach and 'everyone uses the same branch' approach. I worked as a Release Engineer in a company that used to former approach and never had any issues.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.