On 9/26/07, Mark Phippard <markphip@gmail.com> wrote:
> Has anyone seen this document Perforce has which compares it to Subversion?
> http://www.perforce.com/perforce/reviews.html
I've seen it, but I don't generally trust such evaluations, from
parties with a vested interest in the outcome. Especially when that
vested interest is money. ;)
> I know a lot of you use Perforce, so I'd be curious what you think.
Right now my shop uses Perforce for the code depot, and Subversion for
everything else. In my opinion, if your repository has a lot of large
binaries, and you have several offsite contributors, or not everybody
is on the same fast LAN, Subversion is always faster. In most other
cases, Perforce is faster, with a few caveats.
Here's my reaction to the main points in the document...
Branching and Merging:
They are right about Subversion 1.3 lacking good internal merge
tracking, but they clearly ignore the python svnmerge scripts, and 1.5
will definitely close this gap. I have to admit, their Revision Graph
GUI is quite nice. The process of creating branches and working copies
in Perforce seems a lot more convoluted to me, than equivalent svn
operations. I do like their "label" features.
Platform dependencies:
Boy are they wrong here! Using autoprops with native line-endings
has always been much more reliable on Subversion.
I had a situation at my last job, where we changed P4 servers from
a Windows 2K3 box to a Linux box, and back, and all the line endings
in every text file in the depot had their line endings doubled during
each transition. This was after running convoluted line-ending
conversion scripts on the depot, as recommended by Perforce support at
the time. We even wrote a script to eliminate these double
line-endings on a working copy, and had a big commit of nothing but
line-ending changes. All the developers were on the same platform --
this was purely a server data format issue. What a joke!
I started with a couple of small Subversion repositories on a
WinXP box at my current company, and moved to a Linux server when we
got the hardware budget. We NEVER had ANY line-ending issues. The
dump/load process between Subversion servers and versions is MUCH
better than Perforce.
Distributed Development:
They are way off here too! They obviously ignore the existence of
SVK, and the fact that SVN working copies are inherently offline.
P4Proxy is a joke. It doesn't even have support for secure transfers
-- it depends on SSH and VPN tunnels for that. P4Proxy is a glorified
cache, and an obvious kludge, to get around the fact that their
clients require a constant server connection to do anything useful.
Scalability and Performance:
While this is debatable, I find Perforce's memory requirements
onerous. They fail to describe the massive servers required to host
3000+ user environments -- each user inherently adds to the P4 server
memory requirements. Partly due to their licensing system, it is
nearly impossible to set up load-balanced clusters of Perforce
servers. This seems to be trivial when using clustered filesystems
with Subversion, and svnsync developments may make this trivial for
servers with discreet filesystems in the future. SVK and Pushmi
currently create lots of ways to make Subversion scalability and
performance unbeatable.
Defect Tracking:
I don't personally see much value to integrating defect tracking
with source control. I like the Trac method, of being able to
reference repository objects from the ticket description. I think
going the other way -- allowing commits to automatically resolve
tickets -- leads to bad developer habits. If closing tickets based on
commits is ever allowed, it should be done exclusively through
continuous integration testing methods. That's all debatable. I think
commit hooks are a better place for defect tracking integration in
general.
Integration with related tools:
Boy do they gloss over the tools "available from open source
community" here! They fail to mention that Perforce has almost no
third party support for tool integration, despite their API. They
create almost all their integration tools in-house, and leave very
little incentive for third party development in this area. Subversion
has them beat by far, here.
Support:
Let's see, how do you compare a single monopolistic source of
support, for proprietary software -- to a wide open market of support
options, for open software that can be endlessly customized? You say
that the free-market support options are "available at additional
cost", and gloss over the fact that you HAVE to pay for the
monopolistic support BEFORE you can really use the proprietary
software. This is just silly.
The rest of the document just reads like an advertisement to me.
The "meat" is usually the operation time comparison charts, but they
are obviously biased here. Commit, update, and status commands for
text files are usually much faster on Perforce, if you have a reliable
connection to the server, and said server has plenty of memory. That
is because most of their client status information is stored on the
server, and is usually cached in server memory. Binary updates can be
faster on a fast network connection, but Subversion binary diff
network transfers are usually faster on updates that don't involve too
many sub-folders.
Subversion really shoots itself in the foot here, by storing
client status information in each and every folder. This is something
CVS really got wrong. Recursive disk IO is usually going to be much
slower than any central database IO. If the working copy were kept in
a single local store, like SVK or Mercurial, speed comparisons would
become trivial, and Subversion would almost always win. Right now, any
P4 vs. SVN speed comparisons are really just comparing specific client
recursive disk IO to client-server network IO. That makes it pretty
easy to set up scenarios where one will always beat the other. I'm
sure they tested on a client with a slow disk and fast LAN, and with a
dedicated server connection. Unfortunately, that's a pretty common
scenario in commercial development environments.
All you need to do is set up a client connected to the server by a
slow and unreliable modem, with a really fast (10K+ RPM) local disk,
and use a filesystem with very efficient metadata and small-file
storage and caching (i.e. ReiserFS3+). Fill up the repo with lots of
large binaries that diff well. In this scenario, Subversion will
usually win. ;)
:) Jred
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 27 04:03:12 2007