I was recently asked to compare Subversion (SVN) to Perforce, and explain why I would choose to implement SVN rather than Perforce as a replacement for an existing CVS installation.

A big reason not to continue looking at Perforce is its lack of support for workflow. I asked a Perforce SE very pointed questions about how to integrate it with other tools that are very common in big shops, and the resulting answers boiled down to

“…you would have to write something to do that”.

As a pure repository management scheme, Perforce is adequate. I have seen, however, very large Perforce depots exhibit performance issues across the wire, and this would be disadvantageous. Their use of client specs (nearly identical to Clearcase’s use of config specs), means that sets of versions are tied to specific view configurations, which if lost or damaged, are nearly impossible to reproduce. This can bring your ability to reproduce builds (and the releases that were promoted from them) to a halt.

Bottom line is that Subversion is a compelling replacement for CVS because

• SVN is faster & more lightweight
• SVN uses common HTTP & HTTPS transport protocol (and thus is stateless and more compact across the wire)
• SVN uses the exact same command namespace as CVS (co => co, ci => ci, add => add, etc.)
• SVN works in virtually every IDE where CVS works

This means that porting CVS-centric automation would less difficult, and would amount to an actual porting effort rather than new development.

Oh, and one more thing: SVN licenses are $0 per developer, per seat. Forever.

Tags: svn, subversion, perforce

Popularity: 31% [?]